From jira-events at lists.jboss.org  Wed Aug  1 00:30:49 2007
From: jira-events at lists.jboss.org (Elias Ross (JIRA))
Date: Wed, 1 Aug 2007 00:30:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMICROCONT-198) jboss-kernel
 and
 jboss-aop-mc-int have compile dependencies on jboss-test and junit
In-Reply-To: <24306414.1185428327176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27989407.1185942649354.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Elias Ross reopened JBMICROCONT-198:
------------------------------------

             
Those dependencies could be made optional.

http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html 


> jboss-kernel and jboss-aop-mc-int have compile dependencies on jboss-test and junit
> -----------------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-198
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-198
>             Project: JBoss MicroContainer
>          Issue Type: Task
>            Reporter: Elias Ross
>
> jboss-test (and its dependencies) and junit are pulled into projects that depend on "jboss-kernel" and "jboss-aop-mc-int" because the project contains child classes of TestCase within src/main/java ... Probably the best way to deal with this is to create a separate jboss-kernel-test and mc-int-test artifacts.
> These dependencies pull in:
> junit\junit\4.1\junit-4.1.jar
> jboss\profiler\jvmti\jboss-profiler-jvmti\1.0.0.CR5\jboss-profiler-jvmti-1.0.0.CR5.jar
> jboss\jboss-test\1.0.4-SNAPSHOT\jboss-test-1.0.4-SNAPSHOT.jar
> which aren't relevant to people's runtime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 00:40:50 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 1 Aug 2007 00:40:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3986) OutOfMemory
 exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25977153.1185943250769.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3986?page=comments#action_12370647 ] 
            
Anil Saldhana commented on JBAS-3986:
-------------------------------------

Are your users doing a web login? If yes, are they logging out? When they log out, are you invalidating the session? A session invalidation routine does flush the security cache. So if 1 user is logging in, on log out, the entry is removed. If not, the entry exists until the cache times out.

If not, set your cache time outs to a lower value. In a high volume system, system resources are precious (Http Sessions, cache objects). You have to set the time outs to a manageable setting.

> OutOfMemory exception due to TimedCachePolicy in JAAS
> -----------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>            Priority: Critical
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 00:59:58 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 1 Aug 2007 00:59:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4584) Upgrade
 JBossMessaging to 1.4.0.CR1
In-Reply-To: <31379004.1185567589124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19580815.1185944398832.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4584?page=comments#action_12370648 ] 
            
Clebert Suconic commented on JBAS-4584:
---------------------------------------

It was an accident... 

I was investigating this issue... 

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114642

and I didn't mean to commit that duh

If you could just revert those lines please!

> Upgrade JBossMessaging to 1.4.0.CR1
> -----------------------------------
>
>                 Key: JBAS-4584
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4584
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JB5-Messaging
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 01:38:49 2007
From: jira-events at lists.jboss.org (David Sheth (JIRA))
Date: Wed, 1 Aug 2007 01:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1029) calling
 getGroupTaskList results in 4N queries being made to the database
Message-ID: <30255553.1185946729350.JavaMail.jira@cloud.prod.atl2.jboss.com>

calling getGroupTaskList results in 4N queries being made to the database
-------------------------------------------------------------------------

                 Key: JBPM-1029
                 URL: http://jira.jboss.com/jira/browse/JBPM-1029
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: David Sheth
         Assigned To: Tom Baeyens


In the seam 2.0.0.Beta 1 dvdstore example, which uses jbpm-jpdl 3.2.1, one of the admin pages lists all the tasks assigned to the group of the admin, allowing the admin to assign one of the tasks to him or herself. In this page, a task represents an order placed in the store.

Each time a new order is placed in the store, the number of tasks on that admin page goes up by one, as would be expected. However, the number of queries used render the page of tasks goes up by 4 each time a new order is placed.

This seems bad. I asked about this in the seam forum, and got this back from Gavin:

--begin quote
AFAIK, this is a jBPM question, not a Seam question, unless you have evidence otherwise.
--end quote

The specific bit of code in the seam bpm libs that is being called is :

return ManagedJbpmContext.instance()
.getGroupTaskList( new ArrayList( Actor.instance().getGroupActorIds() ) );

which is basically just calling getGroupTaskList on an org.jbpm.JbpmContext instance.


Reference to the post in the seam forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114668 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 03:12:50 2007
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Wed, 1 Aug 2007 03:12:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3986) OutOfMemory
 exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <531126.1185952370172.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3986?page=comments#action_12370651 ] 
            
Ramil Israfilov commented on JBAS-3986:
---------------------------------------

During tests we did correct login and  logout and memory was growing. Problem is that TimedCachePolicy as described in javadoc:  "This is a lazy cache policy in that objects are not checked for expiration until they are accessed."
So it means if user A login and logout it will still remain in cache until next login.
and another problem is that TimedCachePolicy is used by default: inside JaasSecurityManagerService.java there is a DefaultCacheObjectFactory class which instantiate TimedCachePolicy

So for a moment in our production environment  we are using my proposition by extending TimedCachePolicy's run() method.
It is up to you to make your product better !


> OutOfMemory exception due to TimedCachePolicy in JAAS
> -----------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>            Priority: Critical
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 04:15:02 2007
From: jira-events at lists.jboss.org (Wolfgang Betz (JIRA))
Date: Wed, 1 Aug 2007 04:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1049)
 WorkingMemory.iterateFactHandles() generates endless loop with 4.0GA.
In-Reply-To: <27861170.1185871797003.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29570362.1185956102271.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Wolfgang Betz closed JBRULES-1049.
----------------------------------

    Resolution: Cannot Reproduce Bug

Mea culpa, sorry, my fault. It is NOT an issue.
I did not use Iterator.next() as i migrated my project from drools 3. There i used  WorkingMemory.getFactHandles().size(). 
As i used to count facts only for JMX remote monitoring, i did not test the iterator based version for some time.
Anyone having the book "Java for Dummies" at a reasonable price? ;-)



> WorkingMemory.iterateFactHandles() generates endless loop with 4.0GA. 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1049
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1049
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Java 1.6.0_02-b06
>            Reporter: Wolfgang Betz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> WorkingMemory.iterateFactHandles() generates endless loop with 4.0GA for a StatefulSession. I think it worked in earlier 4.0 versions. 
> IterateObjects() does not work 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 lists.jboss.org  Wed Aug  1 04:26:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 1 Aug 2007 04:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1028) BI - UDINESE
In-Reply-To: <21387561.1185904369485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2260282.1185956761892.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1028?page=all ]

Ronald van Kuijk closed JBPM-1028.
----------------------------------

    Resolution: Rejected

> BI - UDINESE
> ------------
>
>                 Key: JBPM-1028
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1028
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Web Interface
>         Environment: dsdsds
>            Reporter: Cristiano Brito
>         Assigned To: Tom Baeyens
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> ddsdsds

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 09:55:49 2007
From: jira-events at lists.jboss.org (Ovidiu Nichifor (JIRA))
Date: Wed, 1 Aug 2007 09:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1619) Multiple
	maximized windows
Message-ID: <8587201.1185976549535.JavaMail.jira@cloud.prod.atl2.jboss.com>

Multiple maximized windows
--------------------------

                 Key: JBPORTAL-1619
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1619
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6 Final
            Reporter: Ovidiu Nichifor
         Assigned To: Julien Viet


Once you authenticate (admin/admin) you'll be brought to the default page of the user account. Suppose the default page contains the "Greetings" and "User" portlets. I have noticed something strange that i don't know if it is really a bug or a feature.

If you follow the next steps:
1. with your browser access: http://<hostname>:<port>/portal/auth/portal/default/default/JSPPortletWindow?windowstate=maximized
2. with your browser access: http://<hostname>:<port>/portal/auth/portal/default/default/UserPortletWindow?windowstate=maximized without normalize first the previous maximized window.

you'll have two windows that are both in the maximized state. Now, the portal should present to you the last maximized window.

If you try to normalize/minimize the maximized window, the portal will display the other maximized window instead of bringing you back to the page in the "normal" state (i.e. with all defined portlets on it).
Is this the way it should work? I've been digging in the JBoss Portal 2.6.ALPHA1 source code and i found a "ensureSingleMaximizedWindow" method in the "org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl" file that does nothing - only throws a FixMe exception. Both JBP-2.6.FINAL & JBP-2.6.ALPHA1 have the same behavior on the test case i described so i assume the maximizing strategy hasn't been 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 lists.jboss.org  Wed Aug  1 10:34:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 10:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8517712.1185978889366.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12370695 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Hi Matthew,

I have worked on this today and I think the feature should be working now. I took the liberty of changing your approach somewhat. 
- I sticked to the changes in your extension point definition
- I changed the interface name to XmlElementMapper, this interface only has the accept(Node) method
- The registry will register all the possible configuration elements for an xml element in a set directly sorted according to the specified priority
- The xml adapter factory will iterate through the sorted set and once it finds a mapper that accepts the dom node create the adapter found in the configuration element
With this approach, I was able to simplify the api (the interface has only one method), to simplify and optimize the implementation of the adapter creation (sorting does only happen once) and to get rid of the default implementation of the mapper.

The only thing I do not know is if this approach works for you, so could you please test it for me? The changes are committed to HEAD

Regards,
Koen

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 10:50:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 10:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-125) problem when creating
 a process project when no jbpm installation is selected
Message-ID: <15859629.1185979849250.JavaMail.jira@cloud.prod.atl2.jboss.com>

problem when creating a process project when no jbpm installation is selected
-----------------------------------------------------------------------------

                 Key: GPD-125
                 URL: http://jira.jboss.com/jira/browse/GPD-125
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Koen Aers
         Assigned To: Koen Aers
             Fix For: jBPM JPDL Designer 3.1.0.CR




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:11:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 11:11:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-125) problem when creating a
 process project when no jbpm installation is selected
In-Reply-To: <15859629.1185979849250.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2424465.1185981109772.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-125?page=all ]

Koen Aers closed GPD-125.
-------------------------

    Resolution: Done

> problem when creating a process project when no jbpm installation is selected
> -----------------------------------------------------------------------------
>
>                 Key: GPD-125
>                 URL: http://jira.jboss.com/jira/browse/GPD-125
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:27:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 11:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28723320.1185982069411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers closed GPD-78.
------------------------

    Resolution: Done

I am closing this as I cannot reproduce the problem. Please feel free to reopen it and attach a process that shows the problem.

Regards,
Koen

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  1 11:29:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 1 Aug 2007 11:29:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1023) Default local
 interface is not picked up if class is woven with JBoss AOP
Message-ID: <27657471.1185982189290.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default local interface is not picked up if class is woven with JBoss AOP
-------------------------------------------------------------------------

                 Key: EJBTHREE-1023
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1023
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, EJB 3.0 RC9 - Patch 1
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD


If weaving the following bean

public interface SessionLocal{
   void method();
}

@Stateful
public bean Session implements Session{
   void method(){}
}

following weaving it implements Session AND org.jboss.aop.Advised, i.e. > 1 interface so the local proxy does not get bound into JNDI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:51:28 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:51:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-989) Create performance
 test suite to test failover
In-Reply-To: <26116759.1172673610805.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10762693.1185983488504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-989?page=all ]

Manik Surtani updated JBCACHE-989:
----------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

> Create performance test suite to test failover
> ----------------------------------------------
>
>                 Key: JBCACHE-989
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-989
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Should be ideally integrated into cruise control builds, and should test a variety of configurations including sync and async replication, BR, 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 lists.jboss.org  Wed Aug  1 11:51:29 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 11:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-12) Same JBPM project shared
 with each person having different JBPM installation program
In-Reply-To: <23767681.1165564238792.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31482575.1185983489226.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-12?page=all ]

Koen Aers closed GPD-12.
------------------------

    Resolution: Done

If the jBPM runtime used to define the project got deleted or is at a different location, there may be compilation errors, but the workbench does not crash as before

> Same JBPM project shared with each person having different JBPM installation program
> ------------------------------------------------------------------------------------
>
>                 Key: GPD-12
>                 URL: http://jira.jboss.com/jira/browse/GPD-12
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>         Environment: Eclipse, MyEclipseIDE, JBPM 3.1.2
>            Reporter: Tom Baeyens
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> To duplicate have two development machines with exactly the same versions of the software except have the Window->Preferences->JBoss jBPM installation locations in different places.
> Have one of the people create a jBPM project, zip up that project and send it to the user of machine 2. Then have machine 2 import that project into Eclipse. 
> Everything blows up. Many of the other non-related projects in the project tree also begin displaying erratic behavior.
> If both users now synchronize to have their IDEs point to the same jBPM path on each of their machines, the project opens up 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 lists.jboss.org  Wed Aug  1 11:52:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:52:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-989) Create
 performance test suite to test failover
In-Reply-To: <26116759.1172673610805.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23970700.1185983569380.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-989?page=comments#action_12370713 ] 
            
Manik Surtani commented on JBCACHE-989:
---------------------------------------

Specifically cluster healing/recovery time needs to be measured.

> Create performance test suite to test failover
> ----------------------------------------------
>
>                 Key: JBCACHE-989
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-989
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Should be ideally integrated into cruise control builds, and should test a variety of configurations including sync and async replication, BR, 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 lists.jboss.org  Wed Aug  1 11:52:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:52:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-989) Create
 performance test suite to test failover
In-Reply-To: <26116759.1172673610805.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11848586.1185983569591.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-989?page=all ]

Manik Surtani reassigned JBCACHE-989:
-------------------------------------

    Assignee: Phillip Thurmond  (was: Manik Surtani)

> Create performance test suite to test failover
> ----------------------------------------------
>
>                 Key: JBCACHE-989
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-989
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Phillip Thurmond
>             Fix For: 2.1.0.GA
>
>
> Should be ideally integrated into cruise control builds, and should test a variety of configurations including sync and async replication, BR, 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 lists.jboss.org  Wed Aug  1 11:54:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-905) Perform code
 coverage analysis and add missing unit tests
In-Reply-To: <10530221.1166036318578.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9167569.1185983689354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-905?page=all ]

Manik Surtani updated JBCACHE-905:
----------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

> Perform code coverage analysis and add missing unit tests
> ---------------------------------------------------------
>
>                 Key: JBCACHE-905
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-905
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Hany Mesha
>             Fix For: 2.1.0.GA
>
>
> Using a code coverage tool like Clover:
> 1) Analyse current test suite on Branch_JBossCache_1_4_0
> 2) Put up results on a wiki page
> 3) Link wiki page to this JIRA task as well as the JBossCache wiki page
> 4) Analyse gaps in the test suite and either document (on the wiki) as being too simple/obvious to test or create a unit test for this.
> Once 2.0.0 reaches CR1, perform the same on HEAD (or Branch_JBossCache_2_0_0 by then...)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:56:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-983) State transfer test
 failures ( to do with concurrent eviction and activation )
In-Reply-To: <1037043.1172078435420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30996257.1185983809509.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-983?page=all ]

Manik Surtani closed JBCACHE-983.
---------------------------------

    Resolution: Done

> State transfer test failures ( to do with concurrent eviction and activation )
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-983
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-983
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:14:49 2007
From: jira-events at lists.jboss.org (Eric Miles (JIRA))
Date: Wed, 1 Aug 2007 12:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
Message-ID: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>

Import collision when static inner classes of 2 different classes have same name
--------------------------------------------------------------------------------

                 Key: JBRULES-1053
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
            Reporter: Eric Miles
         Assigned To: Mark Proctor
         Attachments: drools-import-collision-test.tar.gz

I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:14:49 2007
From: jira-events at lists.jboss.org (Eric Miles (JIRA))
Date: Wed, 1 Aug 2007 12:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9807600.1185984889614.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Eric Miles updated JBRULES-1053:
--------------------------------

    Attachment: drools-import-collision-test.tar.gz

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Mark Proctor
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:19:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1098) Provide a
 distributed locking mechanism as an option
In-Reply-To: <14012403.1181296451566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17546031.1185985189481.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1098?page=all ]

Manik Surtani updated JBCACHE-1098:
-----------------------------------

    Fix Version/s: 3.2.0
                       (was: 3.0.0)

> Provide a distributed locking mechanism as an option
> ----------------------------------------------------
>
>                 Key: JBCACHE-1098
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1098
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 3.2.0
>
>
> Inefficient and not scalable, but people have asked for it for very specific use 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 lists.jboss.org  Wed Aug  1 12:19:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-60) Partitioned Cache
Message-ID: <15401655.1185985189886.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-60?page=all ]

Manik Surtani updated JBCACHE-60:
---------------------------------

    Fix Version/s: 3.2.0
                       (was: 3.0.0)

> Partitioned Cache
> -----------------
>
>                 Key: JBCACHE-60
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-60
>             Project: JBoss Cache
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 3.2.0
>
>   Original Estimate: 10 weeks
>  Remaining Estimate: 10 weeks
>
> - Distributed load across multiple nodes in a cluster
> - No replication/redundancy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:19:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:19:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-70) Make JBossCache an
	XAResource
Message-ID: <12425973.1185985190221.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-70?page=all ]

Manik Surtani updated JBCACHE-70:
---------------------------------

    Fix Version/s: 3.2.0
                       (was: 3.0.0)

> Make JBossCache an XAResource
> -----------------------------
>
>                 Key: JBCACHE-70
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-70
>             Project: JBoss Cache
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 3.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 lists.jboss.org  Wed Aug  1 12:22:03 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-65) Query on JBossCache
Message-ID: <17008771.1185985323548.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-65?page=all ]

Manik Surtani updated JBCACHE-65:
---------------------------------

    Fix Version/s: 4.0.0
                       (was: 3.0.0)
         Assignee: Manik Surtani  (was: Bela Ban)

> Query on JBossCache
> -------------------
>
>                 Key: JBCACHE-65
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-65
>             Project: JBoss Cache
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 4.0.0
>
>
> XPath ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:25:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-86) invalidate() across
 cluster on a per-region basis
Message-ID: <24871656.1185985549785.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-86?page=all ]

Manik Surtani updated JBCACHE-86:
---------------------------------

    Fix Version/s: 3.0.0
                       (was: 2.1.0.GA)

> invalidate() across cluster on a per-region basis
> -------------------------------------------------
>
>                 Key: JBCACHE-86
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-86
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 3.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 lists.jboss.org  Wed Aug  1 12:27:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:27:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-107) Extract locks from
 TreeCache into LockingTable
Message-ID: <13582917.1185985670083.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-107?page=all ]

Manik Surtani closed JBCACHE-107.
---------------------------------

    Resolution: Rejected

Rejecting; this may be superfluous with MVCC/Striped locking designs for 3.0.

> Extract locks from TreeCache into LockingTable
> ----------------------------------------------
>
>                 Key: JBCACHE-107
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-107
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Used by LockInterceptor and CreateIfNotExistsInterceptor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:27:51 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 1 Aug 2007 12:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3986) OutOfMemory
 exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11357424.1185985671157.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana updated JBAS-3986:
--------------------------------

    Priority: Major  (was: Critical)

> OutOfMemory exception due to TimedCachePolicy in JAAS
> -----------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.2.2.GA
>
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 12:27:51 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 1 Aug 2007 12:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3986) Active Flushing:
 OutOfMemory exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7244172.1185985671644.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana updated JBAS-3986:
--------------------------------

          Summary: Active Flushing: OutOfMemory exception due to TimedCachePolicy in JAAS  (was: OutOfMemory exception due to TimedCachePolicy in JAAS)
    Fix Version/s: JBossAS-4.2.2.GA

> Active Flushing: OutOfMemory exception due to TimedCachePolicy in JAAS
> ----------------------------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.2.2.GA
>
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 12:27:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:27:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-401) AOP Collection
 CacheSetImpl.add needs to be atomic
Message-ID: <4655244.1185985672051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-401?page=all ]

Manik Surtani reassigned JBCACHE-401:
-------------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> AOP Collection CacheSetImpl.add needs to be atomic
> --------------------------------------------------
>
>                 Key: JBCACHE-401
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-401
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: PojoCache
>            Reporter: Scott Marlow
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>
> CachedSetImpl.add() is not atomic (another thread could be adding the same value at the same time and both threads get past the existence test).
> Current code looks like this:
>    public boolean add(Object o)
>    {
>       if(keySet().contains(o)) // existance test is done under separate lock
>          return false;
>       try {                               // putObject is done under separate lock
>          cache_.putObject(new Fqn(getFqn(), o),o);
>          return true;
>       } catch (CacheException e) {
>          throw new NestedRuntimeException(e);
>       }
>    }
> I think we need to do something like this:
>    public boolean add(Object o)
>    {
>       try {
>          cache_.putIfAbsent(new Fqn(getFqn(), o),o);
>          return true;
>       } catch (CacheException e) {
>          throw new NestedRuntimeException(e);
>       }
>    }
> Will need new api 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 lists.jboss.org  Wed Aug  1 12:29:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:29:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-788) Optimistic locking
 should not REQUIRE transactions!
In-Reply-To: <27121247.1159281521408.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14624844.1185985789276.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-788?page=all ]

Manik Surtani closed JBCACHE-788.
---------------------------------

    Resolution: Rejected

Superfluous in the light of upcoming MVCC changes - JBCACHE-1151

> 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.GA, 1.3.0.GA, 2.0.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 12:31:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-968) Test on 80 node
	cluster
In-Reply-To: <18585896.1170782600399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24464580.1185985909523.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-968?page=comments#action_12370725 ] 
            
Manik Surtani commented on JBCACHE-968:
---------------------------------------

Once we get a hold of a cluster big enough

> Test on 80 node cluster
> -----------------------
>
>                 Key: JBCACHE-968
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-968
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:31:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-968) Test on 80 node
	cluster
In-Reply-To: <18585896.1170782600399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9532174.1185985909666.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-968?page=all ]

Manik Surtani updated JBCACHE-968:
----------------------------------

    Assignee: Phillip Thurmond  (was: Manik Surtani)

> Test on 80 node cluster
> -----------------------
>
>                 Key: JBCACHE-968
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-968
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Phillip Thurmond
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:33:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-617) Pluggable
 optimistic conflict resolution
Message-ID: <503367.1185986029301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-617?page=all ]

Manik Surtani closed JBCACHE-617.
---------------------------------

    Resolution: Rejected

Will be superfluous with MVCC - JBCACHE-1151

> Pluggable optimistic conflict resolution
> ----------------------------------------
>
>                 Key: JBCACHE-617
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-617
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP2
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.1.0.GA
>
>
> Request for child node merge when conflict on Optimistic locking.
> Conflicts include: children addition, removal and modification.
> This would require JBossCache to abstract the conflict resolution and
> enable customers to plugin their own rules on how to solve the conflicts.
> This would be exposed as an API that customers could implement
> according to their business rules.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:35:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-461) Potential bug in
 ReentrantWriterPreferenceReadWriteLock from util.concurrent
Message-ID: <26432240.1185986149301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-461?page=all ]

Manik Surtani closed JBCACHE-461.
---------------------------------

    Resolution: Rejected

May be superfluous with MVCC - JBCACHE-1151 - as this won't rely on lock upgrading at all.

> Potential bug in ReentrantWriterPreferenceReadWriteLock from util.concurrent
> ----------------------------------------------------------------------------
>
>                 Key: JBCACHE-461
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-461
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4, 1.2.4SP1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.1.0.GA
>
>
> Need to discuss on util.concurrent mail list.
> See org.jboss.cache.lock.ReentrantWriterPreference2Readers1WriterLockTest

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 13:09:49 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 1 Aug 2007 13:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7467677.1185988189542.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1053:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Edson Tirelli
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-224) Expose eviction
 management attributes
Message-ID: <24090332.1185992990725.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-224?page=all ]

Manik Surtani updated JBCACHE-224:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Expose eviction management attributes
> -------------------------------------
>
>                 Key: JBCACHE-224
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-224
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We will need to expose the eviction side of management attributes. This is useful for troubleshooting. But keep in mind that it can also depends on the evction policy used as well. Basic ones are:
> 1. How long does the eviction thread take to process the eviction each time? Or the aevergage time?
> 2. What is the current capacity for the event queue?
> 3. How many nodes have been evicted for this wakeup interval and what's the average time it takes?
> 4. How many eviction miss? I.e., try to evict but the node is gone?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-161) Support chain of
	CacheLoaders
Message-ID: <16649251.1185992990563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-161?page=all ]

Manik Surtani updated JBCACHE-161:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Support chain of CacheLoaders
> -----------------------------
>
>                 Key: JBCACHE-161
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-161
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>
> E.g. TcpDelegatingCacheLoader --> JDBCCacheLoader
> First try to find te element from a remote TCP-based Cache. If not found, go to the DB. Wrt storing, we could pick *any* or *all* CacheLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-434) InternalDelegate
 doesn't relocate AOP nodes properly
Message-ID: <5643323.1185992991584.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-434?page=all ]

Manik Surtani updated JBCACHE-434:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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
>         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 lists.jboss.org  Wed Aug  1 14:29:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1004) Genericize POJO
	API
In-Reply-To: <9353345.1173709786762.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28465930.1185992991731.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1004?page=all ]

Manik Surtani updated JBCACHE-1004:
-----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Genericize POJO API
> -------------------
>
>                 Key: JBCACHE-1004
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1004
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Jason T. Greene
>         Assigned To: Jason T. Greene
>
> Use generics where possible and logical

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-3) Expose JGroups
 (protocols, channel) via JMX, provide common JGroups MBean
Message-ID: <26096369.1185992991908.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-3?page=all ]

Manik Surtani updated JBCACHE-3:
--------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Expose JGroups (protocols, channel) via JMX, provide common JGroups MBean
> -------------------------------------------------------------------------
>
>                 Key: JBCACHE-3
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-3
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-30) Multiple MBean
 Configuration Error
Message-ID: <10710160.1185992992128.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-30?page=all ]

Manik Surtani updated JBCACHE-30:
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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
>
> 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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-4) Notification of
 remote modification
Message-ID: <8092708.1185992992261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-4?page=all ]

Manik Surtani updated JBCACHE-4:
--------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Notification of remote modification
> -----------------------------------
>
>                 Key: JBCACHE-4
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-4
>             Project: JBoss Cache
>          Issue Type: Task
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> TreeCache need to emit a node event that is modify by remote
>   only, i.e., local modification won't trigger this event.
>   This event is needed to listen for remote modification when
>   there is a local copy of this instance around so we know that
>   it is dirty. Use cases are: http session repl and TreeCacheAop
>   where after getObject will need a way to know if the underlying
>   fields have been modified remotely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-268) PojoCache
 InternalDelegate can return incorrect AOPInstance object
Message-ID: <12682679.1185992992484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-268?page=all ]

Manik Surtani updated JBCACHE-268:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> PojoCache InternalDelegate can return incorrect AOPInstance object
> ------------------------------------------------------------------
>
>                 Key: JBCACHE-268
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-268
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: PojoCache
>            Reporter: twundke
>         Assigned To: Ben Wang
>
> The getAopInstance(Fqn) method of InternalDelegate currently uses a cache.peek() call to find the AOPInstance object for an FQN. However, I've come across a situation where multiple calls to this method for the same FQN will return different AOPInstance objects.
> To be honest, I'm not sure of the exact situation in which this occurs as I haven't delved deep enough. However, the basic idea is that I have an object graph in the cache, all hanging off one particular root-level object. I then do a fairly major addition/update to a number of children, but don't specifically update the root-level object. After this update I find that InternalDelegate returns a new instance of the AOPInstance class for the root object's FQN, which has now lost its POJO reference etc. This in turn forces a re-creation of the root-level object, which loses a number of transient references that I have set.
> Note that my object graph has a number of circular references back to this root-level object, so I suspect that the AOP machinery is for some reason updating this object during the update of the children, thereby losing the original AOPInstance reference.
> I've put in a quick fix locally that caches references to AOPInstance objects in a HashMap, which follows the idea suggested in the comment for the method. This solves the 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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-413) Split up build.xml
Message-ID: <830639.1185992992672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-413?page=all ]

Manik Surtani updated JBCACHE-413:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Split up build.xml
> ------------------
>
>                 Key: JBCACHE-413
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-413
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> buidl.xml is getting too big. Maybe we should split them up, e.g., split the pojo cache portion is a starter. We can do it as JbossAs with import directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-450) Create a pure
 pojo-based eviction policy
Message-ID: <19443645.1185992992820.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-450?page=all ]

Manik Surtani updated JBCACHE-450:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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
>   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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-706) Integrate JMX
 bindings of JBoss Cache and PojoCache with AS5 and MC
In-Reply-To: <11682451.1153375211296.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2313201.1185992992926.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-706?page=all ]

Manik Surtani updated JBCACHE-706:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Integrate JMX bindings of JBoss Cache and PojoCache with AS5 and MC
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-706
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-706
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>
> This will involve:
> 1.  Adding new JMX MBean interface (is this necessary for the MC?  What about standalone use?)
> 2.  Providing sample XML files
> 3.  Updating documentation

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-204) Externalize
 RegionManager.Capacity parameter
Message-ID: <15870252.1185992993222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-204?page=all ]

Manik Surtani updated JBCACHE-204:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Externalize RegionManager.Capacity parameter
> --------------------------------------------
>
>                 Key: JBCACHE-204
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-204
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> RegionManager.CAPACITY is used to determine the size of the eviction event queue. It is fixed now. We should externalize it later such that we can tune the eviction policy performance. E.g., when the load is heavy, we may need to increase the queue size such that it is not blocking.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1061) BeanShell version
 JBossCache uses does not support entering generic Collections
In-Reply-To: <30779018.1179315412371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1508873.1185992993392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1061?page=all ]

Manik Surtani updated JBCACHE-1061:
-----------------------------------

    Fix Version/s:     (was: 2.0.0.CR2)

> BeanShell version JBossCache uses does not support entering generic Collections
> -------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1061
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1061
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.CR1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> Need to investigate whether there's a more up to date version:
> bsh % lang = new ArrayList<String>();
> // Error: Parser Error: Parse error at line 1, column 121.  Encountered: <

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-479) Cache loader to
 load children as well when loading a node
Message-ID: <8763705.1185992993555.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-479?page=all ]

Manik Surtani updated JBCACHE-479:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Cache loader to load children as well when loading a node
> ---------------------------------------------------------
>
>                 Key: JBCACHE-479
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-479
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: Manik Surtani
>         Assigned To: Ben Wang
>
> Requested by Ben, for failing unit test o.j.c.aop.loader.FileCacheLoaderAopCollectionsTest

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-681) PojoCache to
 handle jdom documentation
Message-ID: <30513551.1185992993787.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-681?page=all ]

Manik Surtani updated JBCACHE-681:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> PojoCache to handle jdom documentation
> --------------------------------------
>
>                 Key: JBCACHE-681
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-681
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>
> Idea is to replicate the jdom tree easily with PojoCache. The fine-grained replication can be more efficient. Also object relationship like cycles and inheritance can be handled automatically as well.
> We will need to come up a more concrete 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 lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-933) PojoCache to
 create a cache wrapper to retry when upgradeexception is encountered
In-Reply-To: <10583316.1168431468423.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21091817.1185992994147.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-933?page=all ]

Manik Surtani updated JBCACHE-933:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.CR1)

> PojoCache to create a cache wrapper to retry when upgradeexception is encountered
> ---------------------------------------------------------------------------------
>
>                 Key: JBCACHE-933
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-933
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>
> Current 2.0 release becuase of lock contention on __JBossInternal__, it becomes much more common to have lock UpgradeException. Solutions are:
> 1. Fix the underlying cache lock algorithm to allow lock upgrade. This can be tricky since it affects lots of other codes.
> 2. Re-try the logic in a Cache wrapper when UpgradeException is encountered.
> I think option #2 is the best route 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 lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-990) PojoCache leaks
	memory
In-Reply-To: <12480846.1172775308924.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26879502.1185992994306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-990?page=all ]

Manik Surtani updated JBCACHE-990:
----------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)

> PojoCache leaks memory
> ----------------------
>
>                 Key: JBCACHE-990
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-990
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.ALPHA2, 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>            Priority: Critical
>
> I've included the test from the forum thread into
> tests/perf/org/jboss/cache/manualtests/PojoCacheMemoryLeakTest.java - note that since this is in the "manualtests" package, it will not be run by cruise control.   
> When running from within my IDE, after about 8 loops it bombs with an OOME.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-561) Create a separate
 META-INF sub-directory for PojoCache
Message-ID: <9514621.1185992994565.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-561?page=all ]

Manik Surtani updated JBCACHE-561:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Create a separate META-INF sub-directory for PojoCache
> ------------------------------------------------------
>
>                 Key: JBCACHE-561
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-561
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Separate the PojoCache configuration from regular TreeCache so that user don't get confused.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-237) When remove a Pojo
 with shared
 Collection instances from cache, will need to restore the original
 reference
Message-ID: <11533311.1185992994717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-237?page=all ]

Manik Surtani updated JBCACHE-237:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> When remove a Pojo with shared Collection instances from cache, will need to restore the original reference
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-237
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-237
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2.3
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Currently when Pojos that share Collection instances (e.g., a List sub-object), during putObject operation, it will be replaced by a corresponding proxy at runtime. But when removeObject is called, we will need to restore the original reference instead of still using the dynamic proxy one. That is we need to ditch the dynamic proxy 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 lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-774) PojoCache to use a
 RPC layer to transmit POJO events
In-Reply-To: <22632405.1158560091387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30989244.1185992994950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-774?page=all ]

Manik Surtani updated JBCACHE-774:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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: Jason T. Greene
>            Priority: Critical
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> 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 lists.jboss.org  Wed Aug  1 14:29:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-830) Incorrect
 serialization of Collection and Map proxies
In-Reply-To: <7833208.1162480452576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30112196.1185992995264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-830?page=all ]

Manik Surtani updated JBCACHE-830:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Incorrect serialization of Collection and Map proxies
> -----------------------------------------------------
>
>                 Key: JBCACHE-830
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-830
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.3.0.GA, 1.4.0.GA, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Ben Wang
>
> The PojoCache Collection and Map proxies implement Serializable but don't do anything to override default serialization.  They have non-transient fields with refs to things like the cache itself, so serializing one of these is a big problem -- you serialize the whole cache.
> Not sure what the best solution to this is. Perhaps use writeReplace()?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-5) AOP HTTP session
 replication under Tomcat 5
Message-ID: <9263794.1185993291684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-5?page=all ]

Manik Surtani reopened JBCACHE-5:
---------------------------------

      Assignee:     (was: Ben Wang)
             

> AOP HTTP session replication under Tomcat 5
> -------------------------------------------
>
>                 Key: JBCACHE-5
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-5
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 10 weeks
>  Remaining Estimate: 10 weeks
>
> - JBossCache with aop/aopc
>   - Implemented any required features to 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 lists.jboss.org  Wed Aug  1 14:34:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-35) Externalize the
 buffer queue size in LRUAlgorithm
Message-ID: <4277759.1185993291909.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani reopened JBCACHE-35:
----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Externalize the buffer queue size in LRUAlgorithm
> -------------------------------------------------
>
>                 Key: JBCACHE-35
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-35
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Currently, the LRUAlgorithm use a hard size of 5000 on the buffer queue to process node eviction. We should make this configurable so it can adapt to different enviornment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-115) beforeEviction()
	callback
Message-ID: <167659.1185993292071.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani reopened JBCACHE-115:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> beforeEviction() callback
> -------------------------
>
>                 Key: JBCACHE-115
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-115
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.1
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-129) Ensure graceful
 handling of marshalling between different versions
Message-ID: <4850730.1185993292217.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-129?page=all ]

Manik Surtani reopened JBCACHE-129:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Ensure graceful handling of marshalling between different versions
> ------------------------------------------------------------------
>
>                 Key: JBCACHE-129
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-129
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>
> backwards compatibility

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-131) Cache Loaders
 (when unshared, 
 and not used with eviction) Should Persist Transient State Upon Startup
Message-ID: <13893507.1185993292601.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-131?page=all ]

Manik Surtani reopened JBCACHE-131:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-131
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-131
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Jimmy Wilson
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>         Attachments: TreeCache.zip
>
>
> Given the following single, unshared cache loader use case in the TreeCache documentation:
> "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store"
> A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability.
> I have modified TreeCache to handle this situation, and I will attach the modified code to 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 lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-139) Node notification
 event that ecludes myself
Message-ID: <17849714.1185993292785.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-139?page=all ]

Manik Surtani reopened JBCACHE-139:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Node notification event that ecludes myself
> -------------------------------------------
>
>                 Key: JBCACHE-139
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-139
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> It will be nice to have a notification mechanism that can exclude myself (who modifies the node in the first place). This is needed in cache invlidation, 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 lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-154) Ability to
 request cache statisics
Message-ID: <5288029.1185993292983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-154?page=all ]

Manik Surtani reopened JBCACHE-154:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Ability to request cache statisics
> ----------------------------------
>
>                 Key: JBCACHE-154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Rich Dredge
>             Fix For: 2.0.0.GA
>
>
> It would be very helpful to retrieve stats about certain regions of the cache such as:
> - Hit/Miss ratio per region
> - Access counts
> - Number of nodes within a region

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-163) Consolidate jboss
 related libraries
Message-ID: <11789149.1185993293152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ]

Manik Surtani reopened JBCACHE-163:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> 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
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>   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 lists.jboss.org  Wed Aug  1 14:34:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-250) Hierarchical
 caches not working when using JBoss service
Message-ID: <29266301.1185993293831.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-250?page=all ]

Manik Surtani reopened JBCACHE-250:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Hierarchical caches not working when using JBoss service
> --------------------------------------------------------
>
>                 Key: JBCACHE-250
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-250
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3
>            Reporter: Nimrod Rivier
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
>  
> I tried to configure a hierarchical cache, composed of a first-level memory-only cache, 
> and a second-level file-only cache. It seems not to work when I the caches are jboss services, 
> but works when I use plain classes. 
> Details: 
> The caches are created as follows: 
> TreeCacheMBean sCacheSecondLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName1, server); 
> TreeCacheMBean sCacheFirstLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName2, server); 
> LocalDelegatingCacheLoader sCacheLoader = new LocalDelegatingCacheLoader(sCacheSecondLevel.getInstance()); 
> sCacheFirstLevel.setCacheLoader(sCacheLoader); 
> I then insert elements into sCacheFirstLevel, and it seems they are not delegated into sCacheSecondLevel . 
> Adding the following did not help
> sCacheFirstLevel.stopService();
> sCacheFirstLevel.startService();
> sCacheSecondLevel.stopService();
> sCacheSecondLevel.startService();
> When I use the following code to create the caches, everything seems to work fine: 
> sCacheSecondLevel = new TreeCache(); 
> sCacheSecondLevel.setCacheLoaderClass"org.jboss.cache.loader.FileCacheLoader"); 
> Properties filecacheLoaderProperties = new Properties(); 
> filecacheLoaderProperties.put("location","c:\\temp\\cache\\requests"); 
> sCacheSecondLevel.setCacheLoaderConfig(filecacheLoaderProperties); 
> sCacheFirstLevel = new TreeCache(); 
> CacheLoader cacheLoader = new LocalDelegatingCacheLoader (sCacheSecondLevel); 
> sCacheFirstLevel.setCacheLoader(cacheLoader); 
> /* Configure the caches (removed) */ 
> sCacheSecondLevel.createService(); 
> sCacheSecondLevel.startService(); 
> sCacheFirstLevel.createService(); 
> sCacheFirstLevel.startService(); 
>  
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-270) Create a
 notification interceptor
Message-ID: <4864511.1185993294045.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-270?page=all ]

Manik Surtani reopened JBCACHE-270:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Create a notification interceptor
> ---------------------------------
>
>                 Key: JBCACHE-270
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-270
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4beta
>            Reporter: Hany Mesha
>             Fix For: 2.0.0.GA
>
>
> The need has arised to create a notification interceptor to handle the callbacks results from different method call events and interceptors emitted events.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-328) Move attributes
 and getters/setters to interceptors
Message-ID: <28914460.1185993294233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ]

Manik Surtani reopened JBCACHE-328:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> 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
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-332) Webdav interface
 for accessing JBossCache
Message-ID: <5667562.1185993294371.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani reopened JBCACHE-332:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Webdav interface for accessing JBossCache
> -----------------------------------------
>
>                 Key: JBCACHE-332
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-332
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>
> Provide a webdav interface for JBossCache. This will enable access, e.g. from Windows Explorer. Any file dragged into a folder will be replicated 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 lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-347) Replay tx if tx
 is created implicitly and fails on commit
Message-ID: <6556542.1185993294458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-347?page=all ]

Manik Surtani reopened JBCACHE-347:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Replay tx if tx is created implicitly and fails on commit
> ---------------------------------------------------------
>
>                 Key: JBCACHE-347
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-347
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> With optimistic locking, we first check for an existing transaction, and if there isn't one, we implicitly start one. Before the method returns, if we started the tx ourselves, we make sure we commit it. 
> There is scope to 'replay' the tx a fixed number of times here if the commit fails.
> At the moment, if the developer explicitly starts a tx before any cache operations, the cache may throw a RollbackException if it is unable to commit. If the developer doesn't explicitly start a tx, the cache may fail silently if it is unable to commit, logging errors but not throwing any exceptions. So there is scope here for silent retries without changing usage semantics.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-431) Remove jboss-XXX
 JARs which contain Nested(Runtime)Exceptions
Message-ID: <23793641.1185993294676.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-431?page=all ]

Manik Surtani reopened JBCACHE-431:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Remove jboss-XXX JARs which contain Nested(Runtime)Exceptions
> -------------------------------------------------------------
>
>                 Key: JBCACHE-431
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-431
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-432)
 PropertyConfigurator:
 investigate how to implement parsing functionality without use of
 PropertyEditor
Message-ID: <22266108.1185993294835.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani reopened JBCACHE-432:
-----------------------------------

      Assignee:     (was: Ben Wang)
             

> PropertyConfigurator: investigate how to implement parsing functionality without use of PropertyEditor
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-432
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-432
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>
> Can you look into whether this is feasible ? If not, can you move this issue to 1.4 ?
> If we could get rid of that class, we could remove jboss-common.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 lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-469) JGroups Channel
 reference to be obtained from a factory
Message-ID: <7378848.1185993295108.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-469?page=all ]

Manik Surtani reopened JBCACHE-469:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> JGroups Channel reference to be obtained from a factory
> -------------------------------------------------------
>
>                 Key: JBCACHE-469
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-469
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> The JChannelFactory (will be available in JGroups 2.3 - see JGRP-112) should be used to get a channel instance.
> The JChannelFactory could be obtained by:
> 1) MBeanServer lookup (look up a JChannelFactoryMBean instance)
> JBossCache config will need:
> + JChannelFactoryMBean name
> + JGroups configured stack name
> JBossCache config will not need:
> - Cluster name
> - JGroups settings
> 2) JChannelFactory instantiation
> JBossCache config will need:
> + Cluster name
> + JGroups settings
> JBossCache config will not need:
> - JChannelFactoryMBean name
> - JGroups configured stack 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 lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-478) Translate docs
	into Italian
Message-ID: <24891230.1185993295213.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-478?page=all ]

Manik Surtani reopened JBCACHE-478:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Translate docs into Italian
> ---------------------------
>
>                 Key: JBCACHE-478
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-478
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: Manik Surtani
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> Translating JBoss Cache documentation to Italian.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-508) JBossCache
 bechmark and performance tuning
Message-ID: <4955285.1185993295336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-508?page=all ]

Manik Surtani reopened JBCACHE-508:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> JBossCache bechmark and performance tuning
> ------------------------------------------
>
>                 Key: JBCACHE-508
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-508
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> I have created this task specifically to document our effort in the bechmark and performance tuning process. I am using this tool that I developed to do perf test:http://jira.jboss.com/jira/browse/JBCACHE-503
> Note this load test only emulates the http session pattern now.
> I will document the numbers here that I have found and discussed with Bela.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-543) Consider
 synchronized(this) instead of a separate lock
Message-ID: <14431044.1185993295642.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-543?page=all ]

Manik Surtani reopened JBCACHE-543:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Consider synchronized(this) instead of a separate lock
> ------------------------------------------------------
>
>                 Key: JBCACHE-543
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-543
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>             Fix For: 2.0.0.GA, 2.0.0.ALPHA2
>
>
> This will save one object per node, not a big deal but something.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-544) Remove
	AbstractNode superclass
Message-ID: <21154356.1185993295765.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-544?page=all ]

Manik Surtani reopened JBCACHE-544:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Remove AbstractNode superclass
> ------------------------------
>
>                 Key: JBCACHE-544
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-544
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>             Fix For: 2.0.0.GA
>
>
> If AbstractNode is not used anywhere, it's basically more code to maintain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-519) Investigate why
 tx has a higher thruput than non-tx under perf test
Message-ID: <14777725.1185993295492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-519?page=all ]

Manik Surtani reopened JBCACHE-519:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Investigate why tx has  a higher thruput than non-tx under perf test
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-519
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-519
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> During the perf test, I have discovered that the throughput with tx is higher than the non-tx one. This is very puzzling. I have asked Scot Marlow to double check it for me. The same. 
> Machines are: dev09 and dev17.
> Here are some breakdown numbers:
> 1. Single thread, 3000 loops, 10 ms sleep interval.
> (a) no tx
> -----
> Total time spent (ms) per thread: 202921 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? false
> is: 14 requests/sec
> (b) tx
> ----
> Total time spent (ms) per thread: 200718 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? true
> is: 14 requests/sec
> 2. 100 threads, 0ms sleep interval
> (a) no tx
> -----
> Total time spent (ms) per thread: 49352 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? false
> is: 404 requests/sec
> -----
> Total time spent (ms) per thread: 61240 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 325 requests/sec
> -------- dev04
> Total time spent (ms) per thread: 78871 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 250 requests/sec
> (b) tx
> -----
> Total time spent (ms) per thread: 68770 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? true
> is: 288 requests/sec
> ----
> Total time spent (ms) per thread: 74575 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 263 requests/sec
> --- dev04
> Total time spent (ms) per thread: 80648 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 242 requests/sec

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-546) Move lock related
 operations to a separate utility, such as NodeLock
Message-ID: <12394863.1185993295914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-546?page=all ]

Manik Surtani reopened JBCACHE-546:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Move lock related operations to a separate utility, such as NodeLock
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-546
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-546
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>             Fix For: 2.0.0.GA, 2.0.0.ALPHA2
>
>
> This is to reduce the amount of methods in Node to keep them fairly succinct.
> The lock in a Node itself could be package-protected so that interactions must happen through 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-553) JBossCache
	throughput II
Message-ID: <1407018.1185993296051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-553?page=all ]

Manik Surtani reopened JBCACHE-553:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> JBossCache throughput II
> ------------------------
>
>                 Key: JBCACHE-553
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-553
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Here are the results using the perf test to run our Atl clustering lab. The machines are: 2X 3.0GHZ Xeon, 4GB Ram, GBSwtich, dedicated, 140GB drive.
> The load condition are:
> 400 clients (total), no sleep, 7kbyte payload
> async:
> Cluster size, throughtput (req/sec)
> 8,                  1270 (8.9MB/sec)
> 4,                  1270
> 2,                  1400
> sync:
> Cluster size, throughtput (req/sec)
> 8,                  432 (3.0MB/sec)
> 4,                  480
> 2,                  700

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-562) Disable cache
 loader when no cacheloader class is specified
Message-ID: <21042526.1185993296213.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-562?page=all ]

Manik Surtani reopened JBCACHE-562:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Disable cache loader when no cacheloader class is specified
> -----------------------------------------------------------
>
>                 Key: JBCACHE-562
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-562
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> In 1.3, we support a new form of cacheloader config. However, it is incovenient to disable the cache loader (previously all we need is to specify cacheloaderclass to empty). We should also support this kind of semantics so we can disable it easily. I propose when do createcacheloader, we also check whether the class name is there or not to decide whether to go ahead. If not, we simply log an info 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-696) Look into
 JDBMCacheLoader
 details and potentially promote as a 'recommended' cache loader?
In-Reply-To: <5384804.1152867851629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17499401.1185993296317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-696?page=all ]

Manik Surtani reopened JBCACHE-696:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader?
> ------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-696
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-696
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.3.0.GA
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-708) EOF exception in
 TcpCacheLoader
In-Reply-To: <3434652.1153423391520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16730436.1185993296482.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-708?page=all ]

Manik Surtani reopened JBCACHE-708:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> EOF exception in TcpCacheLoader
> -------------------------------
>
>                 Key: JBCACHE-708
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-708
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> Happens when a node in the cluster dies.  See last few postings in 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-710) FileCacheLoader
 passivation/activation produces recursive exception when loader.remove
 fails
In-Reply-To: <18265876.1153707611477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30540682.1185993296679.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani reopened JBCACHE-710:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
> --------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-710
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-710
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
> In ActivationInterceptor.java, we have:
>             if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
>                if (n.hasChildren()) {
>                   if (allInitialized(n)) {
>                      log.debug("children all initialized");
>                      remove(fqn);
>                   }
>                } else if (loaderNoChildren(fqn)) {
>                   log.debug("no children " + n);
>                   remove(fqn);
>                }
>             }
>          }
>       }
>       return retval;
>    }
>    private void remove(Fqn fqn) throws Exception {
>       loader.remove(fqn);
>       cache.notifyNodeActivate(fqn, false);
>       if (cache.getUseInterceptorMbeans()&& statsEnabled)
>          m_activations++;
>    }
> problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g.,
> cache.get(fqn, key)
> to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion.
> A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-723) Proper collection
	rollback
In-Reply-To: <9144391.1154091011340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32639121.1185993296830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-723?page=all ]

Manik Surtani reopened JBCACHE-723:
-----------------------------------

      Assignee:     (was: Ben Wang)
             

> Proper collection rollback
> --------------------------
>
>                 Key: JBCACHE-723
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-723
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> It is not properly yet via the undointerceptor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8456951.1185993296953.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani reopened JBCACHE-739:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>             Fix For: 2.0.0.GA, 1.4.1.GA
>
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-740) Optimistic
 Locking Scheme: Occasional IllegalStateExceptions on commit
In-Reply-To: <30375980.1155931121396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20937360.1185993297155.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-740?page=all ]

Manik Surtani reopened JBCACHE-740:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Optimistic Locking Scheme: Occasional IllegalStateExceptions on commit
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-740
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-740
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.GA
>         Environment: Linux 2.6.15-26-686 #1 SMP PREEMPT Thu Aug 3 03:13:28 UTC 2006 i686 GNU/Linux
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
> JOTM 2.0.10
> JUnit 3.8.1
>            Reporter: Carsten Krebs
>             Fix For: 2.0.0.BETA1
>
>         Attachments: MultithreadedTxTest.java
>
>
> The unit test below reproduces "occasional" IllegalStateExceptions (s.b.) on commiting a transaction.  This test tries to modify the same node at the same time by different threads in different transactions using the optimistic locking scheme.
> java.lang.IllegalStateException: there is already a writer holding the lock: GlobalTransaction:<null>:43
> 	at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:96)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:204)
> 	at org.jboss.cache.Node.acquireWriteLock(Node.java:431)
> 	at org.jboss.cache.Node.acquire(Node.java:386)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:149)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:76)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
> 	at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
> 	at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
> 	at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1487)
> 	at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:416)
> 	at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:239)
> 	at OptimisticLockingTest$Worker.run(OptimisticLockingTest.java:135)
> The Cache Config:
> -------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <server>
>     <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
> 		<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>	
>         <attribute name="CacheMode">LOCAL</attribute>
>     </mbean>
> </server>   
> The Unit Test:
> -------------------
> import javax.transaction.Transaction;
> import javax.transaction.TransactionManager;
> import junit.framework.TestCase;
> import org.jboss.cache.CacheException;
> import org.jboss.cache.PropertyConfigurator;
> import org.jboss.cache.TransactionManagerLookup;
> import org.jboss.cache.TreeCache;
> import org.objectweb.jotm.Current;
> import EDU.oswego.cs.dl.util.concurrent.CyclicBarrier;
> /**
>  * OptimisticLockingTest
>  */
> public class OptimisticLockingTest extends TestCase {
> 	private static final String NODE_PATH = "/path/node";
> 	private static final String KEY = "key";
> 	private static final Current jotm = new Current();
> 	private TreeCache cache;
> 	protected void setUp() throws Exception {
> 		super.setUp();
> 		cache = new TreeCache();
> 		final PropertyConfigurator config = new PropertyConfigurator();
> 		cache.setTransactionManagerLookup(new TransactionManagerLookup() {
> 			public TransactionManager getTransactionManager() throws Exception {
> 				return Current.getTransactionManager();
> 			}
> 		});
> 		config.configure(cache, this.getClass().getResourceAsStream(
> 				"/cache-config.xml"));
> 		cache.startService();
> 	}
> 	public void testSimultanWrite() throws Exception {
> 		for (int i = 2; i < 20; i++) {
> 			System.out.println(">> testing simultaneous writes with " + i
> 					+ " threads...");
> 			testSimultanWrite(i);
> 		}
> 	}
> 	public void testSimultanWrite(final int _numThreads) throws Exception {
> 		final CyclicBarrier barrier = new CyclicBarrier(_numThreads);
> 		Worker[] workers = new Worker[_numThreads];
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i] = new Worker();
> 			workers[i].barrier = barrier;
> 			workers[i].value = "worker" + i;
> 			if (i == 0) {
> 				workers[i].isMaster = true;
> 			}
> 			workers[i].start();
> 		}
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i].join();
> 		}
> 		assertNull(workers[0].exception);
> 		for (int i = 0; i < workers.length; i++) {
> 			assertNull("rollback failed", workers[i].rollbackException);
> 		}
> 		for (int i = 1; i < workers.length; i++) {
> 			assertNotNull("missing exception", workers[i].exception);
> 			assertTrue("exception is not of type CacheException",
> 					workers[i].exception.getCause() instanceof CacheException);
> 		}
> 		assertEquals("worker0", cache.get(NODE_PATH, KEY));
> 		cache.getTransactionManager().begin();
> 		cache.remove(NODE_PATH);
> 		cache.getTransactionManager().commit();
> 	}
> 	private class Worker extends Thread {
> 		private CyclicBarrier barrier;
> 		private Exception exception;
> 		private Exception rollbackException;
> 		private String value;
> 		private boolean isMaster;
> 		/**
> 		 * @see java.lang.Thread#run()
> 		 */
> 		public void run() {
> 			final TransactionManager txManager = cache.getTransactionManager();
> 			Transaction tx = null;
> 			try {
> 				// wait for all threads started
> 				barrier.barrier();
> 				if (isMaster) {
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// lets the other threads start writing
> 					barrier.barrier();
> 					// wait for other threads to their modification
> 					barrier.barrier();
> 					// commit first
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 					// lets the other threads commit
> 					barrier.barrier();
> 				} else {
> 					// wait for master to start transaction
> 					barrier.barrier();
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// signal modification
> 					barrier.barrier();
> 					// wait for master to commit transaction
> 					barrier.barrier();
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 				}
> 			} catch (Exception e) {
> 				exception = e;
> 				try {
> 					tx.rollback();
> 				} catch (Exception e1) {
> 					rollbackException = e1;
> 				}
> 			}
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-806) Invalidation
 causes problems
 with otimistic data versioning and certain edge cases
In-Reply-To: <10131954.1160555681818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27955589.1185993297620.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-806?page=all ]

Manik Surtani reopened JBCACHE-806:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Invalidation causes problems with otimistic data versioning and certain edge cases
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-806
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-806
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0.SP1
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA, 1.4.1.GA
>
>         Attachments: OptimisticAsyncInvalidationTest.java, OptimisticSyncInvalidationTest.java
>
>
> Related to JBCACHE-793, but that has more to do with fixing the recommended configurations.
> From email conversations:
> Manik >>
> At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB.  If CacheB has V2 already, the invalidation will fail.  What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory.  Am I correct?
> Max >>
> It wasn't the scenario I had in mind, but this one is probably also relevant.
> Manik >>
> Or is the scenario you're trying to paint more like:
> V2 put into CacheA.  CacheB has V1, gets the invalidation msg, and V1 is evicted.  Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache?  This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache.
> Max >>
> This is the scenario I had in mind yes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-833) Redundant lock in
	cache loader
In-Reply-To: <23674490.1162796741672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28950381.1185993297799.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-833?page=all ]

Manik Surtani reopened JBCACHE-833:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Redundant lock in cache loader
> ------------------------------
>
>                 Key: JBCACHE-833
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-833
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.4.0.SP1
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> Currently in CacheLoader, it calls "lock" from loadIfNeeded method. The "lock" method in turns invokes 
> TreeCache.java
>    public void _lock(Fqn fqn, DataNode.LockType lock_type, boolean recursive)
>            throws TimeoutException, LockingException
>    {
>       log.warn("method _lock() should not be invoked on TreeCache");
>    }
> I think the LockInterceptor should take care of the locking properly. So this call should be deprecated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-839) PojoCache to add
 an option to replicate final field
In-Reply-To: <6374929.1162975184638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28612273.1185993298036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-839?page=all ]

Manik Surtani reopened JBCACHE-839:
-----------------------------------

      Assignee:     (was: Jason T. Greene)
             

> PojoCache to add an option to replicate final field
> ---------------------------------------------------
>
>                 Key: JBCACHE-839
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-839
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> We should add a flag to enable replication of final field in PojoCache. This can be done via pojocache-aop.xml, where:
>    <!-- Begining of interceptor chain -->
>    <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor"
>                 scope="PER_INSTANCE">
>       <!-- If set to true, will also replicate final field. -->
>          <attribute name="ReplicateFinalField">true</attribute>
>     </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 lists.jboss.org  Wed Aug  1 14:34:58 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-853) CacheJmxWrapper
 should implement NotificationBroadcaster
In-Reply-To: <28775885.1163711081674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9155797.1185993298198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-853?page=all ]

Manik Surtani reopened JBCACHE-853:
-----------------------------------

      Assignee:     (was: Brian Stansberry)
             

> CacheJmxWrapper should implement NotificationBroadcaster
> --------------------------------------------------------
>
>                 Key: JBCACHE-853
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-853
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.GA
>
>
> We need to clarify responsibility for this between the top level JMX wrapper beans and CacheMgmtInterceptor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:58 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-877) TreeCache usage
 should not depend on trove.jar
In-Reply-To: <25606358.1164359621709.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23618632.1185993298782.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-877?page=all ]

Manik Surtani reopened JBCACHE-877:
-----------------------------------

      Assignee:     (was: Galder Zamarreno)
             

> TreeCache usage should not depend on trove.jar
> ----------------------------------------------
>
>                 Key: JBCACHE-877
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-877
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 2.0.0.BETA1, 1.4.1.SP2
>            Reporter: Galder Zamarreno
>            Priority: Minor
>             Fix For: 2.0.0.CR1
>
>         Attachments: jbosscache.log
>
>
> A customer is upgrading from JBC 1.1 to 1.4.0.SP1 and 
> even though it only uses plain TreeCache, it gets a 
> NoClassDefFoundError for trove classes.
> 2006-11-23 13:19:03,781  ERROR RpcDispatcher exception=java.lang.NoClassDefFoundError: gnu/trove/TObjectHashingStrategy
> This is a TreeCacheAop/PojoCache dependency and therefore,
> should be isolated and attempted to be loaded only when 
> PojoCache 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 lists.jboss.org  Wed Aug  1 14:34:59 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-882) Migrating JBC 1.x
 java serialized data to 2.x VAM format
In-Reply-To: <23712522.1164720235826.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7607334.1185993299683.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-882?page=all ]

Manik Surtani reopened JBCACHE-882:
-----------------------------------

      Assignee:     (was: Galder Zamarreno)
             

> Migrating JBC 1.x java serialized data to 2.x VAM format
> --------------------------------------------------------
>
>                 Key: JBCACHE-882
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-882
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.ALPHA1
>            Reporter: Galder Zamarreno
>             Fix For: 2.0.0.BETA2, 2.0.0.GA
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Write an FAQ entry in which to explain how to transform 
> data stored in 1.x format into the VAM format.
> Explanation will focus on: "Write a 'bridge' app, which 
> starts 2 instances of JBC (old and new -  can these even 
> run in the same VM together?) and yanks data out of 
> one and into the other?"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:59 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-885) Bug when calling
 putObject() with array as argument
In-Reply-To: <23372676.1164808257741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10002321.1185993299834.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-885?page=all ]

Manik Surtani reopened JBCACHE-885:
-----------------------------------

      Assignee:     (was: Ben Wang)
             

> Bug when calling putObject() with array as argument
> ---------------------------------------------------
>
>                 Key: JBCACHE-885
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-885
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Bela Ban
>             Fix For: 2.0.0.ALPHA2
>
>
> Should at least not lead to an exception, we could for example state that we don't support arrays yet.
> To reproduce:
> TreeCacheAop cache;
> long arr=new long[]{1,2};
> cache.putObject("arr", arr);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:59 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-912) Fix tutorial
In-Reply-To: <9853821.1166635899738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24213981.1185993299934.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-912?page=all ]

Manik Surtani reopened JBCACHE-912:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Fix tutorial
> ------------
>
>                 Key: JBCACHE-912
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-912
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>             Fix For: 1.4.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 lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-995) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
In-Reply-To: <14344696.1172881209074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1884646.1185993300061.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-995?page=all ]

Manik Surtani reopened JBCACHE-995:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-995
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-995
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Rajesh Rajasekaran
>             Fix For: 2.0.0.BETA2
>
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-996) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
Message-ID: <10017690.1185993300201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-996?page=all ]

Manik Surtani reopened JBCACHE-996:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-996
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-996
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Rajesh Rajasekaran
>             Fix For: 2.0.0.BETA2
>
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest 
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1030) CR1 Build
 failing - aopc now requires concurrent.jar
In-Reply-To: <7016274.1177089570271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32355333.1185993300366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1030?page=all ]

Manik Surtani reopened JBCACHE-1030:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> CR1 Build failing - aopc now requires concurrent.jar
> ----------------------------------------------------
>
>                 Key: JBCACHE-1030
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1030
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA2
>         Environment: windows ant 1.6.5
>            Reporter: Bill Middleton
>             Fix For: 2.0.0.CR1
>
>
> The aop.InterceptionMarkers.<init> fails during the build of aopc-pojocache, due to the lack of ConcurrentReaderHashMap (from oswego).  Placing a copy of concurrent.jar into $JBOSS_CACHE/lib fixes the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1083) Look at inlining
 MarshalledValue, etc. and ditching jboss-common.jar
In-Reply-To: <28557342.1180602068355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28776053.1185993300457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1083?page=all ]

Manik Surtani reopened JBCACHE-1083:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> Look at inlining MarshalledValue, etc. and ditching jboss-common.jar
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-1083
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1083
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.CR1
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA, 2.0.0.CR3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1107) All notifier
 calls to be in a separate thread
In-Reply-To: <25158705.1181750831742.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31199428.1185993300572.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1107?page=all ]

Manik Surtani reopened JBCACHE-1107:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> All notifier calls to be in a separate thread
> ---------------------------------------------
>
>                 Key: JBCACHE-1107
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1107
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA, 2.0.0.CR3
>
>
> Using an executor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1108) Move
 CacheListeners to their own thread pool
In-Reply-To: <21972953.1181751071690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11769361.1185993300720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1108?page=all ]

Manik Surtani reopened JBCACHE-1108:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> Move CacheListeners to their own thread pool
> --------------------------------------------
>
>                 Key: JBCACHE-1108
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1108
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>             Fix For: 2.0.0.CR3
>
>
> User CacheListeners should be dispatched in their own thread pool to prevent reentrancy problems and delays on cache operations. 
> Evection listeners should still be executed in the app thread.
> -Jason

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1140) JGroups MBeans
 should be bound to JMX if JBC MBeans are bound as well
In-Reply-To: <25932628.1184617847035.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13324175.1185993300815.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1140?page=all ]

Manik Surtani reopened JBCACHE-1140:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> JGroups MBeans should be bound to JMX if JBC MBeans are bound as well
> ---------------------------------------------------------------------
>
>                 Key: JBCACHE-1140
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1140
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP3
>            Reporter: Manik Surtani
>             Fix For: 1.4.1.SP4
>
>
> Forum ref posted is not specific to this case, but here is a comment to this effect by Bela pretty early in the thread.
> http://wiki.jboss.org/wiki/Wiki.jsp?page=JMX

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1149) FIFOPolicy is
 adding a visited node to the evictionqueue
In-Reply-To: <8548353.1185183227344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5369877.1185993300946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1149?page=all ]

Manik Surtani reopened JBCACHE-1149:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> FIFOPolicy is adding a visited node to the evictionqueue
> --------------------------------------------------------
>
>                 Key: JBCACHE-1149
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1149
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eviction, MonthOfBugs_200
>    Affects Versions: 2.0.0.CR2
>         Environment: OS: WIn XP SP2; JBOSS AS: 4.0.3; Cache : 2.0.0CR2
>            Reporter: Maddulety Vankadara
>             Fix For: 2.0.0.GA
>
>
> Created Eviction Policy with the following config:
>       <attribute name="EvictionPolicyConfig">
>          <config>
>             <attribute name="wakeUpIntervalSeconds">30</attribute>
>             <attribute name="eventQueueSize">200000</attribute>
>             <!-- Cache wide default -->
>             <region name="/_default_" policyClass="org.jboss.cache.eviction.FIFOPolicy">
>                <attribute name="maxNodes">500</attribute>
>             </region>
>          </config>
>       </attribute>
> And then created a region programmatically and assigned FIFOPolicy to that region.
> FIFOConfiguration evictionConfig = new FIFOConfiguration();
> evictionConfig.setMaxNodes(CacheConstants.60);
> Region rn = getCache().getRegion(Fqn.fromString("\a\b\c"), true);
> rn.setEvictionPolicy(evictionConfig);
> Add some nodes under "/a/b/c". All nodes are added to the evictionqueue properly. 
> But when I traverse  the region /a/b/c,  This node is also added to the evictionqueue and when the queue reaches the limit "MAXNodes"( which is 60 here), the node /a/b/c is evicted from cache.
> I think a visted node should not be evicted in a FIFO policy. 
> After going through the code, I noticed that VISIT_NODE_EVENT is not ignored in the FIFOPolicy class.
> Overriding the bemow method in org.jboss.cache.eviction.FIFOPolicy will fix the issue:
> public boolean canIgnoreEvent(Fqn fqn, NodeEventType eventType) {
>          return (eventType == NodeEventType.VISIT_NODE_EVENT);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11054721.1185993301112.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani updated JBCACHE-739:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 1.4.1.GA)

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-912) Fix tutorial
In-Reply-To: <9853821.1166635899738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30905318.1185993301215.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-912?page=all ]

Manik Surtani updated JBCACHE-912:
----------------------------------

    Fix Version/s:     (was: 1.4.1.GA)

> Fix tutorial
> ------------
>
>                 Key: JBCACHE-912
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-912
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:35:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-806) Invalidation
 causes problems
 with otimistic data versioning and certain edge cases
In-Reply-To: <10131954.1160555681818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14399936.1185993301468.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-806?page=all ]

Manik Surtani updated JBCACHE-806:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 1.4.1.GA)

> Invalidation causes problems with otimistic data versioning and certain edge cases
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-806
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-806
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0.SP1
>            Reporter: Manik Surtani
>         Attachments: OptimisticAsyncInvalidationTest.java, OptimisticSyncInvalidationTest.java
>
>
> Related to JBCACHE-793, but that has more to do with fixing the recommended configurations.
> From email conversations:
> Manik >>
> At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB.  If CacheB has V2 already, the invalidation will fail.  What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory.  Am I correct?
> Max >>
> It wasn't the scenario I had in mind, but this one is probably also relevant.
> Manik >>
> Or is the scenario you're trying to paint more like:
> V2 put into CacheA.  CacheB has V1, gets the invalidation msg, and V1 is evicted.  Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache?  This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache.
> Max >>
> This is the scenario I had in mind yes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:37:02 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2170265.1185993422331.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani closed JBCACHE-739.
---------------------------------

    Resolution: Done

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:37:02 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25968581.1185993422564.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani reopened JBCACHE-739:
-----------------------------------

             

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:37:02 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14481903.1185993422749.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani closed JBCACHE-739.
---------------------------------

    Resolution: Rejected

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:38:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-806) Invalidation causes
 problems with otimistic data versioning and certain edge cases
In-Reply-To: <10131954.1160555681818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27927410.1185993529596.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-806?page=all ]

Manik Surtani closed JBCACHE-806.
---------------------------------

    Resolution: Duplicate Issue

JBCACHE-1155

> Invalidation causes problems with otimistic data versioning and certain edge cases
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-806
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-806
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0.SP1
>            Reporter: Manik Surtani
>         Attachments: OptimisticAsyncInvalidationTest.java, OptimisticSyncInvalidationTest.java
>
>
> Related to JBCACHE-793, but that has more to do with fixing the recommended configurations.
> From email conversations:
> Manik >>
> At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB.  If CacheB has V2 already, the invalidation will fail.  What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory.  Am I correct?
> Max >>
> It wasn't the scenario I had in mind, but this one is probably also relevant.
> Manik >>
> Or is the scenario you're trying to paint more like:
> V2 put into CacheA.  CacheB has V1, gets the invalidation msg, and V1 is evicted.  Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache?  This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache.
> Max >>
> This is the scenario I had in mind yes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:38:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-912) Fix tutorial
In-Reply-To: <9853821.1166635899738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1237410.1185993529723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-912?page=all ]

Manik Surtani closed JBCACHE-912.
---------------------------------

    Resolution: Rejected

> Fix tutorial
> ------------
>
>                 Key: JBCACHE-912
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-912
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:40:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-543) Consider
 synchronized(this) instead of a separate lock
Message-ID: <11445464.1185993649404.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-543?page=all ]

Manik Surtani closed JBCACHE-543.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.ALPHA2)
       Resolution: Rejected

> Consider synchronized(this) instead of a separate lock
> ------------------------------------------------------
>
>                 Key: JBCACHE-543
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-543
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>
> This will save one object per node, not a big deal but something.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:40:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-546) Move lock related
 operations to a separate utility, such as NodeLock
Message-ID: <21742107.1185993649530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-546?page=all ]

Manik Surtani closed JBCACHE-546.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.ALPHA2)
       Resolution: Rejected

> Move lock related operations to a separate utility, such as NodeLock
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-546
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-546
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>
> This is to reduce the amount of methods in Node to keep them fairly succinct.
> The lock in a Node itself could be package-protected so that interactions must happen through 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 lists.jboss.org  Wed Aug  1 14:40:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-885) Bug when calling
 putObject() with array as argument
In-Reply-To: <23372676.1164808257741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1315859.1185993649698.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-885?page=all ]

Manik Surtani closed JBCACHE-885.
---------------------------------

    Fix Version/s:     (was: 2.0.0.ALPHA2)
       Resolution: Rejected

> Bug when calling putObject() with array as argument
> ---------------------------------------------------
>
>                 Key: JBCACHE-885
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-885
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Bela Ban
>
> Should at least not lead to an exception, we could for example state that we don't support arrays yet.
> To reproduce:
> TreeCacheAop cache;
> long arr=new long[]{1,2};
> cache.putObject("arr", arr);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-740) Optimistic Locking
 Scheme: Occasional IllegalStateExceptions on commit
In-Reply-To: <30375980.1155931121396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <915685.1185993769479.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-740?page=all ]

Manik Surtani closed JBCACHE-740.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA1)
       Resolution: Cannot Reproduce Bug

> Optimistic Locking Scheme: Occasional IllegalStateExceptions on commit
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-740
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-740
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.GA
>         Environment: Linux 2.6.15-26-686 #1 SMP PREEMPT Thu Aug 3 03:13:28 UTC 2006 i686 GNU/Linux
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
> JOTM 2.0.10
> JUnit 3.8.1
>            Reporter: Carsten Krebs
>         Attachments: MultithreadedTxTest.java
>
>
> The unit test below reproduces "occasional" IllegalStateExceptions (s.b.) on commiting a transaction.  This test tries to modify the same node at the same time by different threads in different transactions using the optimistic locking scheme.
> java.lang.IllegalStateException: there is already a writer holding the lock: GlobalTransaction:<null>:43
> 	at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:96)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:204)
> 	at org.jboss.cache.Node.acquireWriteLock(Node.java:431)
> 	at org.jboss.cache.Node.acquire(Node.java:386)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:149)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:76)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
> 	at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
> 	at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
> 	at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1487)
> 	at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:416)
> 	at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:239)
> 	at OptimisticLockingTest$Worker.run(OptimisticLockingTest.java:135)
> The Cache Config:
> -------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <server>
>     <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
> 		<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>	
>         <attribute name="CacheMode">LOCAL</attribute>
>     </mbean>
> </server>   
> The Unit Test:
> -------------------
> import javax.transaction.Transaction;
> import javax.transaction.TransactionManager;
> import junit.framework.TestCase;
> import org.jboss.cache.CacheException;
> import org.jboss.cache.PropertyConfigurator;
> import org.jboss.cache.TransactionManagerLookup;
> import org.jboss.cache.TreeCache;
> import org.objectweb.jotm.Current;
> import EDU.oswego.cs.dl.util.concurrent.CyclicBarrier;
> /**
>  * OptimisticLockingTest
>  */
> public class OptimisticLockingTest extends TestCase {
> 	private static final String NODE_PATH = "/path/node";
> 	private static final String KEY = "key";
> 	private static final Current jotm = new Current();
> 	private TreeCache cache;
> 	protected void setUp() throws Exception {
> 		super.setUp();
> 		cache = new TreeCache();
> 		final PropertyConfigurator config = new PropertyConfigurator();
> 		cache.setTransactionManagerLookup(new TransactionManagerLookup() {
> 			public TransactionManager getTransactionManager() throws Exception {
> 				return Current.getTransactionManager();
> 			}
> 		});
> 		config.configure(cache, this.getClass().getResourceAsStream(
> 				"/cache-config.xml"));
> 		cache.startService();
> 	}
> 	public void testSimultanWrite() throws Exception {
> 		for (int i = 2; i < 20; i++) {
> 			System.out.println(">> testing simultaneous writes with " + i
> 					+ " threads...");
> 			testSimultanWrite(i);
> 		}
> 	}
> 	public void testSimultanWrite(final int _numThreads) throws Exception {
> 		final CyclicBarrier barrier = new CyclicBarrier(_numThreads);
> 		Worker[] workers = new Worker[_numThreads];
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i] = new Worker();
> 			workers[i].barrier = barrier;
> 			workers[i].value = "worker" + i;
> 			if (i == 0) {
> 				workers[i].isMaster = true;
> 			}
> 			workers[i].start();
> 		}
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i].join();
> 		}
> 		assertNull(workers[0].exception);
> 		for (int i = 0; i < workers.length; i++) {
> 			assertNull("rollback failed", workers[i].rollbackException);
> 		}
> 		for (int i = 1; i < workers.length; i++) {
> 			assertNotNull("missing exception", workers[i].exception);
> 			assertTrue("exception is not of type CacheException",
> 					workers[i].exception.getCause() instanceof CacheException);
> 		}
> 		assertEquals("worker0", cache.get(NODE_PATH, KEY));
> 		cache.getTransactionManager().begin();
> 		cache.remove(NODE_PATH);
> 		cache.getTransactionManager().commit();
> 	}
> 	private class Worker extends Thread {
> 		private CyclicBarrier barrier;
> 		private Exception exception;
> 		private Exception rollbackException;
> 		private String value;
> 		private boolean isMaster;
> 		/**
> 		 * @see java.lang.Thread#run()
> 		 */
> 		public void run() {
> 			final TransactionManager txManager = cache.getTransactionManager();
> 			Transaction tx = null;
> 			try {
> 				// wait for all threads started
> 				barrier.barrier();
> 				if (isMaster) {
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// lets the other threads start writing
> 					barrier.barrier();
> 					// wait for other threads to their modification
> 					barrier.barrier();
> 					// commit first
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 					// lets the other threads commit
> 					barrier.barrier();
> 				} else {
> 					// wait for master to start transaction
> 					barrier.barrier();
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// signal modification
> 					barrier.barrier();
> 					// wait for master to commit transaction
> 					barrier.barrier();
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 				}
> 			} catch (Exception e) {
> 				exception = e;
> 				try {
> 					tx.rollback();
> 				} catch (Exception e1) {
> 					rollbackException = e1;
> 				}
> 			}
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1140) JGroups MBeans
 should be bound to JMX if JBC MBeans are bound as well
In-Reply-To: <25932628.1184617847035.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17076396.1185993769703.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1140?page=all ]

Manik Surtani closed JBCACHE-1140.
----------------------------------

    Fix Version/s:     (was: 1.4.1.SP4)
       Resolution: Cannot Reproduce Bug

> JGroups MBeans should be bound to JMX if JBC MBeans are bound as well
> ---------------------------------------------------------------------
>
>                 Key: JBCACHE-1140
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1140
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP3
>            Reporter: Manik Surtani
>
> Forum ref posted is not specific to this case, but here is a comment to this effect by Bela pretty early in the thread.
> http://wiki.jboss.org/wiki/Wiki.jsp?page=JMX

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-882) Migrating JBC 1.x
 java serialized data to 2.x VAM format
In-Reply-To: <23712522.1164720235826.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16945327.1185993769871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-882?page=all ]

Manik Surtani closed JBCACHE-882.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)
                       (was: 2.0.0.GA)
       Resolution: Rejected

> Migrating JBC 1.x java serialized data to 2.x VAM format
> --------------------------------------------------------
>
>                 Key: JBCACHE-882
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-882
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.ALPHA1
>            Reporter: Galder Zamarreno
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Write an FAQ entry in which to explain how to transform 
> data stored in 1.x format into the VAM format.
> Explanation will focus on: "Write a 'bridge' app, which 
> starts 2 instances of JBC (old and new -  can these even 
> run in the same VM together?) and yanks data out of 
> one and into the other?"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-996) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
Message-ID: <16511541.1185993770172.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-996?page=all ]

Manik Surtani closed JBCACHE-996.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)
       Resolution: Rejected

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-996
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-996
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Rajesh Rajasekaran
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest 
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:42:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-995) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
In-Reply-To: <14344696.1172881209074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23488809.1185993770019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-995?page=all ]

Manik Surtani closed JBCACHE-995.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)
       Resolution: Rejected

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-995
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-995
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Rajesh Rajasekaran
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:44:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-877) TreeCache usage
 should not depend on trove.jar
In-Reply-To: <25606358.1164359621709.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18122084.1185993893976.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-877?page=all ]

Manik Surtani closed JBCACHE-877.
---------------------------------

    Fix Version/s:     (was: 2.0.0.CR1)
       Resolution: Rejected

> TreeCache usage should not depend on trove.jar
> ----------------------------------------------
>
>                 Key: JBCACHE-877
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-877
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 2.0.0.BETA1, 1.4.1.SP2
>            Reporter: Galder Zamarreno
>            Priority: Minor
>         Attachments: jbosscache.log
>
>
> A customer is upgrading from JBC 1.1 to 1.4.0.SP1 and 
> even though it only uses plain TreeCache, it gets a 
> NoClassDefFoundError for trove classes.
> 2006-11-23 13:19:03,781  ERROR RpcDispatcher exception=java.lang.NoClassDefFoundError: gnu/trove/TObjectHashingStrategy
> This is a TreeCacheAop/PojoCache dependency and therefore,
> should be isolated and attempted to be loaded only when 
> PojoCache 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 lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1030) CR1 Build failing
 - aopc now requires concurrent.jar
In-Reply-To: <7016274.1177089570271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13394092.1185993894128.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1030?page=all ]

Manik Surtani closed JBCACHE-1030.
----------------------------------

    Fix Version/s:     (was: 2.0.0.CR1)
       Resolution: Rejected

> CR1 Build failing - aopc now requires concurrent.jar
> ----------------------------------------------------
>
>                 Key: JBCACHE-1030
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1030
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA2
>         Environment: windows ant 1.6.5
>            Reporter: Bill Middleton
>
> The aop.InterceptionMarkers.<init> fails during the build of aopc-pojocache, due to the lack of ConcurrentReaderHashMap (from oswego).  Placing a copy of concurrent.jar into $JBOSS_CACHE/lib fixes the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1083) Look at inlining
 MarshalledValue, etc. and ditching jboss-common.jar
In-Reply-To: <28557342.1180602068355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17718920.1185993894211.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1083?page=all ]

Manik Surtani closed JBCACHE-1083.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.CR3)
       Resolution: Rejected

> Look at inlining MarshalledValue, etc. and ditching jboss-common.jar
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-1083
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1083
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.CR1
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1107) All notifier calls
 to be in a separate thread
In-Reply-To: <25158705.1181750831742.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24931902.1185993894298.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1107?page=all ]

Manik Surtani closed JBCACHE-1107.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.CR3)
       Resolution: Rejected

> All notifier calls to be in a separate thread
> ---------------------------------------------
>
>                 Key: JBCACHE-1107
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1107
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>
> Using an executor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1108) Move
 CacheListeners to their own thread pool
In-Reply-To: <21972953.1181751071690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5802783.1185993894441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1108?page=all ]

Manik Surtani closed JBCACHE-1108.
----------------------------------

    Fix Version/s:     (was: 2.0.0.CR3)
       Resolution: Rejected

> Move CacheListeners to their own thread pool
> --------------------------------------------
>
>                 Key: JBCACHE-1108
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1108
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>
> User CacheListeners should be dispatched in their own thread pool to prevent reentrancy problems and delays on cache operations. 
> Evection listeners should still be executed in the app thread.
> -Jason

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-5) AOP HTTP session
 replication under Tomcat 5
Message-ID: <23023754.1185994010742.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-5?page=all ]

Manik Surtani closed JBCACHE-5.
-------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> AOP HTTP session replication under Tomcat 5
> -------------------------------------------
>
>                 Key: JBCACHE-5
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-5
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>   Original Estimate: 10 weeks
>  Remaining Estimate: 10 weeks
>
> - JBossCache with aop/aopc
>   - Implemented any required features to 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 lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-35) Externalize the
 buffer queue size in LRUAlgorithm
Message-ID: <23214965.1185994011104.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani closed JBCACHE-35.
--------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Externalize the buffer queue size in LRUAlgorithm
> -------------------------------------------------
>
>                 Key: JBCACHE-35
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-35
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>            Priority: Minor
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Currently, the LRUAlgorithm use a hard size of 5000 on the buffer queue to process node eviction. We should make this configurable so it can adapt to different enviornment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-115) beforeEviction()
	callback
Message-ID: <9107940.1185994011339.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani closed JBCACHE-115.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> beforeEviction() callback
> -------------------------
>
>                 Key: JBCACHE-115
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-115
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.1
>            Reporter: Bela Ban
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-129) Ensure graceful
 handling of marshalling between different versions
Message-ID: <11618776.1185994011551.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-129?page=all ]

Manik Surtani closed JBCACHE-129.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Ensure graceful handling of marshalling between different versions
> ------------------------------------------------------------------
>
>                 Key: JBCACHE-129
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-129
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>
> backwards compatibility

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-131) Cache Loaders (when
 unshared, 
 and not used with eviction) Should Persist Transient State Upon Startup
Message-ID: <30975284.1185994011709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-131?page=all ]

Manik Surtani closed JBCACHE-131.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-131
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-131
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Jimmy Wilson
>            Priority: Minor
>         Attachments: TreeCache.zip
>
>
> Given the following single, unshared cache loader use case in the TreeCache documentation:
> "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store"
> A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability.
> I have modified TreeCache to handle this situation, and I will attach the modified code to 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 lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-139) Node notification
 event that ecludes myself
Message-ID: <10160651.1185994011939.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-139?page=all ]

Manik Surtani closed JBCACHE-139.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Node notification event that ecludes myself
> -------------------------------------------
>
>                 Key: JBCACHE-139
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-139
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> It will be nice to have a notification mechanism that can exclude myself (who modifies the node in the first place). This is needed in cache invlidation, 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 lists.jboss.org  Wed Aug  1 14:46:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-154) Ability to request
 cache statisics
Message-ID: <13546384.1185994012096.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-154?page=all ]

Manik Surtani closed JBCACHE-154.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Ability to request cache statisics
> ----------------------------------
>
>                 Key: JBCACHE-154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Rich Dredge
>
> It would be very helpful to retrieve stats about certain regions of the cache such as:
> - Hit/Miss ratio per region
> - Access counts
> - Number of nodes within a region

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-163) Consolidate jboss
 related libraries
Message-ID: <32979997.1185994012256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ]

Manik Surtani closed JBCACHE-163.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> 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
>            Priority: Minor
>   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 lists.jboss.org  Wed Aug  1 14:46:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-250) Hierarchical caches
 not working when using JBoss service
Message-ID: <1596682.1185994012806.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-250?page=all ]

Manik Surtani closed JBCACHE-250.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Hierarchical caches not working when using JBoss service
> --------------------------------------------------------
>
>                 Key: JBCACHE-250
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-250
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3
>            Reporter: Nimrod Rivier
>            Priority: Minor
>
>  
> I tried to configure a hierarchical cache, composed of a first-level memory-only cache, 
> and a second-level file-only cache. It seems not to work when I the caches are jboss services, 
> but works when I use plain classes. 
> Details: 
> The caches are created as follows: 
> TreeCacheMBean sCacheSecondLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName1, server); 
> TreeCacheMBean sCacheFirstLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName2, server); 
> LocalDelegatingCacheLoader sCacheLoader = new LocalDelegatingCacheLoader(sCacheSecondLevel.getInstance()); 
> sCacheFirstLevel.setCacheLoader(sCacheLoader); 
> I then insert elements into sCacheFirstLevel, and it seems they are not delegated into sCacheSecondLevel . 
> Adding the following did not help
> sCacheFirstLevel.stopService();
> sCacheFirstLevel.startService();
> sCacheSecondLevel.stopService();
> sCacheSecondLevel.startService();
> When I use the following code to create the caches, everything seems to work fine: 
> sCacheSecondLevel = new TreeCache(); 
> sCacheSecondLevel.setCacheLoaderClass"org.jboss.cache.loader.FileCacheLoader"); 
> Properties filecacheLoaderProperties = new Properties(); 
> filecacheLoaderProperties.put("location","c:\\temp\\cache\\requests"); 
> sCacheSecondLevel.setCacheLoaderConfig(filecacheLoaderProperties); 
> sCacheFirstLevel = new TreeCache(); 
> CacheLoader cacheLoader = new LocalDelegatingCacheLoader (sCacheSecondLevel); 
> sCacheFirstLevel.setCacheLoader(cacheLoader); 
> /* Configure the caches (removed) */ 
> sCacheSecondLevel.createService(); 
> sCacheSecondLevel.startService(); 
> sCacheFirstLevel.createService(); 
> sCacheFirstLevel.startService(); 
>  
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-270) Create a
 notification interceptor
Message-ID: <8189831.1185994013018.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-270?page=all ]

Manik Surtani closed JBCACHE-270.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Create a notification interceptor
> ---------------------------------
>
>                 Key: JBCACHE-270
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-270
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4beta
>            Reporter: Hany Mesha
>
> The need has arised to create a notification interceptor to handle the callbacks results from different method call events and interceptors emitted events.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-328) Move attributes and
 getters/setters to interceptors
Message-ID: <3749117.1185994013170.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ]

Manik Surtani closed JBCACHE-328.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> 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
>
> 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 lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-332) Webdav interface
 for accessing JBossCache
Message-ID: <21407812.1185994013310.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani closed JBCACHE-332.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Webdav interface for accessing JBossCache
> -----------------------------------------
>
>                 Key: JBCACHE-332
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-332
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>
> Provide a webdav interface for JBossCache. This will enable access, e.g. from Windows Explorer. Any file dragged into a folder will be replicated 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 lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-347) Replay tx if tx is
 created implicitly and fails on commit
Message-ID: <17637401.1185994013394.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-347?page=all ]

Manik Surtani closed JBCACHE-347.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Replay tx if tx is created implicitly and fails on commit
> ---------------------------------------------------------
>
>                 Key: JBCACHE-347
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-347
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>
> With optimistic locking, we first check for an existing transaction, and if there isn't one, we implicitly start one. Before the method returns, if we started the tx ourselves, we make sure we commit it. 
> There is scope to 'replay' the tx a fixed number of times here if the commit fails.
> At the moment, if the developer explicitly starts a tx before any cache operations, the cache may throw a RollbackException if it is unable to commit. If the developer doesn't explicitly start a tx, the cache may fail silently if it is unable to commit, logging errors but not throwing any exceptions. So there is scope here for silent retries without changing usage semantics.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-431) Remove jboss-XXX
 JARs which contain Nested(Runtime)Exceptions
Message-ID: <15945694.1185994013593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-431?page=all ]

Manik Surtani closed JBCACHE-431.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Remove jboss-XXX JARs which contain Nested(Runtime)Exceptions
> -------------------------------------------------------------
>
>                 Key: JBCACHE-431
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-431
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-432)
 PropertyConfigurator:
 investigate how to implement parsing functionality without use of
 PropertyEditor
Message-ID: <27835803.1185994015179.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani closed JBCACHE-432.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> PropertyConfigurator: investigate how to implement parsing functionality without use of PropertyEditor
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-432
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-432
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>
> Can you look into whether this is feasible ? If not, can you move this issue to 1.4 ?
> If we could get rid of that class, we could remove jboss-common.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 lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-469) JGroups Channel
 reference to be obtained from a factory
Message-ID: <3875529.1185994015272.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-469?page=all ]

Manik Surtani closed JBCACHE-469.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> JGroups Channel reference to be obtained from a factory
> -------------------------------------------------------
>
>                 Key: JBCACHE-469
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-469
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>
> The JChannelFactory (will be available in JGroups 2.3 - see JGRP-112) should be used to get a channel instance.
> The JChannelFactory could be obtained by:
> 1) MBeanServer lookup (look up a JChannelFactoryMBean instance)
> JBossCache config will need:
> + JChannelFactoryMBean name
> + JGroups configured stack name
> JBossCache config will not need:
> - Cluster name
> - JGroups settings
> 2) JChannelFactory instantiation
> JBossCache config will need:
> + Cluster name
> + JGroups settings
> JBossCache config will not need:
> - JChannelFactoryMBean name
> - JGroups configured stack 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 lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-478) Translate docs into
	Italian
Message-ID: <17523596.1185994015352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-478?page=all ]

Manik Surtani closed JBCACHE-478.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Translate docs into Italian
> ---------------------------
>
>                 Key: JBCACHE-478
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-478
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: Manik Surtani
>            Priority: Minor
>
> Translating JBoss Cache documentation to Italian.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-508) JBossCache bechmark
 and performance tuning
Message-ID: <15831918.1185994015496.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-508?page=all ]

Manik Surtani closed JBCACHE-508.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> JBossCache bechmark and performance tuning
> ------------------------------------------
>
>                 Key: JBCACHE-508
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-508
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>
> I have created this task specifically to document our effort in the bechmark and performance tuning process. I am using this tool that I developed to do perf test:http://jira.jboss.com/jira/browse/JBCACHE-503
> Note this load test only emulates the http session pattern now.
> I will document the numbers here that I have found and discussed with Bela.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-519) Investigate why tx
 has a higher thruput than non-tx under perf test
Message-ID: <29212255.1185994015627.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-519?page=all ]

Manik Surtani closed JBCACHE-519.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Investigate why tx has  a higher thruput than non-tx under perf test
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-519
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-519
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>
> During the perf test, I have discovered that the throughput with tx is higher than the non-tx one. This is very puzzling. I have asked Scot Marlow to double check it for me. The same. 
> Machines are: dev09 and dev17.
> Here are some breakdown numbers:
> 1. Single thread, 3000 loops, 10 ms sleep interval.
> (a) no tx
> -----
> Total time spent (ms) per thread: 202921 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? false
> is: 14 requests/sec
> (b) tx
> ----
> Total time spent (ms) per thread: 200718 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? true
> is: 14 requests/sec
> 2. 100 threads, 0ms sleep interval
> (a) no tx
> -----
> Total time spent (ms) per thread: 49352 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? false
> is: 404 requests/sec
> -----
> Total time spent (ms) per thread: 61240 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 325 requests/sec
> -------- dev04
> Total time spent (ms) per thread: 78871 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 250 requests/sec
> (b) tx
> -----
> Total time spent (ms) per thread: 68770 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? true
> is: 288 requests/sec
> ----
> Total time spent (ms) per thread: 74575 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 263 requests/sec
> --- dev04
> Total time spent (ms) per thread: 80648 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 242 requests/sec

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-544) Remove AbstractNode
	superclass
Message-ID: <21243550.1185994015752.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-544?page=all ]

Manik Surtani closed JBCACHE-544.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Remove AbstractNode superclass
> ------------------------------
>
>                 Key: JBCACHE-544
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-544
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>
> If AbstractNode is not used anywhere, it's basically more code to maintain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-553) JBossCache
	throughput II
Message-ID: <17725825.1185994015886.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-553?page=all ]

Manik Surtani closed JBCACHE-553.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> JBossCache throughput II
> ------------------------
>
>                 Key: JBCACHE-553
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-553
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Here are the results using the perf test to run our Atl clustering lab. The machines are: 2X 3.0GHZ Xeon, 4GB Ram, GBSwtich, dedicated, 140GB drive.
> The load condition are:
> 400 clients (total), no sleep, 7kbyte payload
> async:
> Cluster size, throughtput (req/sec)
> 8,                  1270 (8.9MB/sec)
> 4,                  1270
> 2,                  1400
> sync:
> Cluster size, throughtput (req/sec)
> 8,                  432 (3.0MB/sec)
> 4,                  480
> 2,                  700

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-562) Disable cache
 loader when no cacheloader class is specified
Message-ID: <12943774.1185994016051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-562?page=all ]

Manik Surtani closed JBCACHE-562.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Disable cache loader when no cacheloader class is specified
> -----------------------------------------------------------
>
>                 Key: JBCACHE-562
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-562
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Priority: Minor
>
> In 1.3, we support a new form of cacheloader config. However, it is incovenient to disable the cache loader (previously all we need is to specify cacheloaderclass to empty). We should also support this kind of semantics so we can disable it easily. I propose when do createcacheloader, we also check whether the class name is there or not to decide whether to go ahead. If not, we simply log an info 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-696) Look into
 JDBMCacheLoader
 details and potentially promote as a 'recommended' cache loader?
In-Reply-To: <5384804.1152867851629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30710497.1185994016150.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-696?page=all ]

Manik Surtani closed JBCACHE-696.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader?
> ------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-696
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-696
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.3.0.GA
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-708) EOF exception in
	TcpCacheLoader
In-Reply-To: <3434652.1153423391520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32215013.1185994016300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-708?page=all ]

Manik Surtani closed JBCACHE-708.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> EOF exception in TcpCacheLoader
> -------------------------------
>
>                 Key: JBCACHE-708
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-708
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Manik Surtani
>
> Happens when a node in the cluster dies.  See last few postings in 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-710) FileCacheLoader
 passivation/activation produces recursive exception when loader.remove
 fails
In-Reply-To: <18265876.1153707611477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17059011.1185994016494.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani closed JBCACHE-710.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
> --------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-710
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-710
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Ben Wang
>            Priority: Minor
>
> I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
> In ActivationInterceptor.java, we have:
>             if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
>                if (n.hasChildren()) {
>                   if (allInitialized(n)) {
>                      log.debug("children all initialized");
>                      remove(fqn);
>                   }
>                } else if (loaderNoChildren(fqn)) {
>                   log.debug("no children " + n);
>                   remove(fqn);
>                }
>             }
>          }
>       }
>       return retval;
>    }
>    private void remove(Fqn fqn) throws Exception {
>       loader.remove(fqn);
>       cache.notifyNodeActivate(fqn, false);
>       if (cache.getUseInterceptorMbeans()&& statsEnabled)
>          m_activations++;
>    }
> problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g.,
> cache.get(fqn, key)
> to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion.
> A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-723) Proper collection
	rollback
In-Reply-To: <9144391.1154091011340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4368499.1185994016695.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-723?page=all ]

Manik Surtani closed JBCACHE-723.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Proper collection rollback
> --------------------------
>
>                 Key: JBCACHE-723
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-723
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>
> It is not properly yet via the undointerceptor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-833) Redundant lock in
	cache loader
In-Reply-To: <23674490.1162796741672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2259499.1185994016822.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-833?page=all ]

Manik Surtani closed JBCACHE-833.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Redundant lock in cache loader
> ------------------------------
>
>                 Key: JBCACHE-833
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-833
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.4.0.SP1
>            Reporter: Ben Wang
>            Priority: Minor
>
> Currently in CacheLoader, it calls "lock" from loadIfNeeded method. The "lock" method in turns invokes 
> TreeCache.java
>    public void _lock(Fqn fqn, DataNode.LockType lock_type, boolean recursive)
>            throws TimeoutException, LockingException
>    {
>       log.warn("method _lock() should not be invoked on TreeCache");
>    }
> I think the LockInterceptor should take care of the locking properly. So this call should be deprecated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-839) PojoCache to add an
 option to replicate final field
In-Reply-To: <6374929.1162975184638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12865116.1185994016983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-839?page=all ]

Manik Surtani closed JBCACHE-839.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> PojoCache to add an option to replicate final field
> ---------------------------------------------------
>
>                 Key: JBCACHE-839
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-839
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>
> We should add a flag to enable replication of final field in PojoCache. This can be done via pojocache-aop.xml, where:
>    <!-- Begining of interceptor chain -->
>    <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor"
>                 scope="PER_INSTANCE">
>       <!-- If set to true, will also replicate final field. -->
>          <attribute name="ReplicateFinalField">true</attribute>
>     </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 lists.jboss.org  Wed Aug  1 14:46:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-853) CacheJmxWrapper
 should implement NotificationBroadcaster
In-Reply-To: <28775885.1163711081674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22052583.1185994017156.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-853?page=all ]

Manik Surtani closed JBCACHE-853.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> CacheJmxWrapper should implement NotificationBroadcaster
> --------------------------------------------------------
>
>                 Key: JBCACHE-853
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-853
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>
> We need to clarify responsibility for this between the top level JMX wrapper beans and CacheMgmtInterceptor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1149) FIFOPolicy is
 adding a visited node to the evictionqueue
In-Reply-To: <8548353.1185183227344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11678473.1185994017396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1149?page=all ]

Manik Surtani closed JBCACHE-1149.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> FIFOPolicy is adding a visited node to the evictionqueue
> --------------------------------------------------------
>
>                 Key: JBCACHE-1149
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1149
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eviction, MonthOfBugs_200
>    Affects Versions: 2.0.0.CR2
>         Environment: OS: WIn XP SP2; JBOSS AS: 4.0.3; Cache : 2.0.0CR2
>            Reporter: Maddulety Vankadara
>
> Created Eviction Policy with the following config:
>       <attribute name="EvictionPolicyConfig">
>          <config>
>             <attribute name="wakeUpIntervalSeconds">30</attribute>
>             <attribute name="eventQueueSize">200000</attribute>
>             <!-- Cache wide default -->
>             <region name="/_default_" policyClass="org.jboss.cache.eviction.FIFOPolicy">
>                <attribute name="maxNodes">500</attribute>
>             </region>
>          </config>
>       </attribute>
> And then created a region programmatically and assigned FIFOPolicy to that region.
> FIFOConfiguration evictionConfig = new FIFOConfiguration();
> evictionConfig.setMaxNodes(CacheConstants.60);
> Region rn = getCache().getRegion(Fqn.fromString("\a\b\c"), true);
> rn.setEvictionPolicy(evictionConfig);
> Add some nodes under "/a/b/c". All nodes are added to the evictionqueue properly. 
> But when I traverse  the region /a/b/c,  This node is also added to the evictionqueue and when the queue reaches the limit "MAXNodes"( which is 60 here), the node /a/b/c is evicted from cache.
> I think a visted node should not be evicted in a FIFO policy. 
> After going through the code, I noticed that VISIT_NODE_EVENT is not ignored in the FIFOPolicy class.
> Overriding the bemow method in org.jboss.cache.eviction.FIFOPolicy will fix the issue:
> public boolean canIgnoreEvent(Fqn fqn, NodeEventType eventType) {
>          return (eventType == NodeEventType.VISIT_NODE_EVENT);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:53:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-857) Upgrade to JBoss
 AOP 2.0.ALPHA2
In-Reply-To: <10223338.1163733821459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26059199.1185994429326.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani reopened JBCACHE-857:
-----------------------------------

      Assignee: Manik Surtani  (was: Ben Wang)
             

> Upgrade to JBoss AOP 2.0.ALPHA2
> -------------------------------
>
>                 Key: JBCACHE-857
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-857
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> Temporarily upgrade to 2.0.ALPHA2 for the alpha release such tat we can continue integration into AS5.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-857) Upgrade to JBoss
	AOP 2.0.ALPHA2
In-Reply-To: <10223338.1163733821459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32668773.1185994566180.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani closed JBCACHE-857.
---------------------------------

    Resolution: Rejected

> Upgrade to JBoss AOP 2.0.ALPHA2
> -------------------------------
>
>                 Key: JBCACHE-857
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-857
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> Temporarily upgrade to 2.0.ALPHA2 for the alpha release such tat we can continue integration into AS5.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-654) Upgrade to JBoss
 AOP 2.0 to prevent classloader memory leakage during re-deployment
Message-ID: <29364336.1185994566360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-654?page=all ]

Manik Surtani updated JBCACHE-654:
----------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

Moving to a release when AOP 2.0 will be avbl!

> Upgrade to JBoss AOP 2.0 to prevent classloader memory leakage during re-deployment
> -----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-654
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-654
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-967) Upgrade to
	JGroups 2.4.SP1
In-Reply-To: <671116.1170632843598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14111363.1185994566439.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-967?page=all ]

Manik Surtani reopened JBCACHE-967:
-----------------------------------

             

> Upgrade to JGroups 2.4.SP1
> --------------------------
>
>                 Key: JBCACHE-967
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-967
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.CR1
>
>
> This fixes MUX/State transfer test failures present with 2.4.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-967) Upgrade to JGroups
	2.4.SP1
In-Reply-To: <671116.1170632843598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1032053.1185994566515.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-967?page=all ]

Manik Surtani closed JBCACHE-967.
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)
                       (was: 2.0.0.BETA2)
       Resolution: Done

> Upgrade to JGroups 2.4.SP1
> --------------------------
>
>                 Key: JBCACHE-967
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-967
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.CR1
>
>
> This fixes MUX/State transfer test failures present with 2.4.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-884) Upgrade to
	JGroups 2.4.1
In-Reply-To: <11844620.1164808136361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15806710.1185994566676.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-884?page=all ]

Manik Surtani reopened JBCACHE-884:
-----------------------------------

             

> Upgrade to JGroups 2.4.1
> ------------------------
>
>                 Key: JBCACHE-884
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-884
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.GA
>
>
> As a part of this, rely on JGroups ANYCAST (JBCACHE-813) properly, and yank out JBCACHE-813 kludge.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-884) Upgrade to JGroups
	2.4.1
In-Reply-To: <11844620.1164808136361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25012075.1185994566780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-884?page=all ]

Manik Surtani closed JBCACHE-884.
---------------------------------

    Fix Version/s:     (was: 2.0.0.ALPHA2)
                       (was: 2.0.0.GA)
       Resolution: Done

> Upgrade to JGroups 2.4.1
> ------------------------
>
>                 Key: JBCACHE-884
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-884
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.GA
>
>
> As a part of this, rely on JGroups ANYCAST (JBCACHE-813) properly, and yank out JBCACHE-813 kludge.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-886) Upgrading from
 JGroups 2.2.9.2 to JGroups 2.4
In-Reply-To: <4570210.1164810896031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18859640.1185994669523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-886?page=all ]

Manik Surtani reopened JBCACHE-886:
-----------------------------------

             

> Upgrading from JGroups 2.2.9.2 to JGroups 2.4
> ---------------------------------------------
>
>                 Key: JBCACHE-886
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-886
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-886) Upgrading from
 JGroups 2.2.9.2 to JGroups 2.4
In-Reply-To: <4570210.1164810896031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30146199.1185994669674.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-886?page=all ]

Manik Surtani closed JBCACHE-886.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Done

> Upgrading from JGroups 2.2.9.2 to JGroups 2.4
> ---------------------------------------------
>
>                 Key: JBCACHE-886
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-886
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1020) Upgrade to
	JGroups 2.5.BETA2
In-Reply-To: <12027656.1175601658413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17968570.1185994669783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1020?page=all ]

Manik Surtani reopened JBCACHE-1020:
------------------------------------

             

> Upgrade to JGroups 2.5.BETA2
> ----------------------------
>
>                 Key: JBCACHE-1020
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1020
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA2
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1020) Upgrade to JGroups
	2.5.BETA2
In-Reply-To: <12027656.1175601658413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12798251.1185994669875.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1020?page=all ]

Manik Surtani closed JBCACHE-1020.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Done

> Upgrade to JGroups 2.5.BETA2
> ----------------------------
>
>                 Key: JBCACHE-1020
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1020
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA2
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-470) Update JBoss
 Cache to use JGroups 2.4 and Multiplexer
Message-ID: <21387539.1185994669965.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Manik Surtani reopened JBCACHE-470:
-----------------------------------

      Assignee: Manik Surtani  (was: Jerry Gauthier)
             

> 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: Manik Surtani
>            Priority: Blocker
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:59:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-470) Update JBoss Cache
 to use JGroups Multiplexer
Message-ID: <16927205.1185994789267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Manik Surtani updated JBCACHE-470:
----------------------------------

    Summary: Update JBoss Cache to use JGroups Multiplexer  (was: Update JBoss Cache to use JGroups 2.4 and Multiplexer)

> Update JBoss Cache to use JGroups 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: Manik Surtani
>            Priority: Blocker
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:59:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-470) Update JBoss Cache
 to use JGroups Multiplexer
Message-ID: <14991776.1185994789350.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Manik Surtani closed JBCACHE-470.
---------------------------------

    Resolution: Done

> Update JBoss Cache to use JGroups 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: Manik Surtani
>            Priority: Blocker
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 15:24:49 2007
From: jira-events at lists.jboss.org (Hany Mesha (JIRA))
Date: Wed, 1 Aug 2007 15:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
In-Reply-To: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23534893.1185996289528.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Hany Mesha resolved JBAS-3720.
------------------------------

    Resolution: Done
      Assignee: Brian Stansberry  (was: Hany Mesha)

changed the fqn for sessions map in TreeCacheSSOClusterManager 

The change is done in the following method:

private Fqn getSessionsFqn(String ssoid)
   {
      Object[] objs = new Object[]{SSO, ssoid, localAddress, SESSIONS};
      return new Fqn(objs);
   }

Note that the original fqn didn't have localAddress as part of the node structure in the tree cache. With this change the sessions associated with the SSO ID will be identified by the server that this SSO cluster manager running on.

Brian, Please confirm the change and close the issue. Thanks!

Due to the fact that the test suite is broken, I didn't have chance to test this change. However, there's no special test cases that need to be written to verify the change. So once the test suite is repaired, the verification would be running the SSO test cases to success.



> 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 lists.jboss.org  Wed Aug  1 15:36:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 1 Aug 2007 15:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1024) jndi multiplexer
 broken for list() and listBindings()
Message-ID: <11875388.1185997009377.JavaMail.jira@cloud.prod.atl2.jboss.com>

jndi multiplexer broken for list() and listBindings()
-----------------------------------------------------

                 Key: EJBTHREE-1024
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1024
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.0 GA
            Reporter: William DeCoste
         Assigned To: William DeCoste




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 15:36:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 1 Aug 2007 15:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1024) jndi multiplexer
 broken for list() and listBindings()
In-Reply-To: <11875388.1185997009377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28986639.1185997009556.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste closed EJBTHREE-1024.
-------------------------------------

    Fix Version/s: AS 4.2.2.GA
       Resolution: Done

> jndi multiplexer broken for list() and listBindings()
> -----------------------------------------------------
>
>                 Key: EJBTHREE-1024
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1024
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.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 lists.jboss.org  Wed Aug  1 18:25:49 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 1 Aug 2007 18:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1050) Extra space
 between variable and field name in LHS causes crash
In-Reply-To: <11262114.1185887149714.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32083173.1186007149894.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-1050.
------------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

Fixed.

Changed parser to ignore comments and white spaces when parsing nested accessors paths and qualified identifiers. Unit test added. Following expression is correctly parsed:

"org   .   drools/*comment*/\t  .Message( text not matches $c#comment\n. property )\n";
        assertEquals( "org.drools.Message", 
                      pat.getObjectType() );
        assertEquals( "not matches",
                      restr.getEvaluator() );
        assertEquals( "$c.property",
                      restr.getText() );
 
Thanks for reporting and providing test case. Fix will be included in 4.0.1.
 

> Extra space between variable and field name in LHS causes crash
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1050
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1050
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Writing a condition as "$co:Item(attachment in ($c, $c. parent))" fails at runtime with an uninformative exception. Removing the extra space and writing "$c.parent" corrects the problem.
> Below is the rule file, sample code and exception trace.
> package com.sample
>  
> import com.sample.DroolsTest.Child;
> import com.sample.DroolsTest.Parent;
> import com.sample.DroolsTest.Item;
>  
> rule "My Rule"
> 	
> 	when
> 		$c:Child()
> 		$co:Item(attachment in ($c, $c. parent))
> 	then
> 		System.out.println("wawa");
> end
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class DroolsTest {
> 	public static final void main(String[] args) {
> 		try {
> 			RuleBase ruleBase = readRule();
> 		} catch (Throwable t) {
> 			t.printStackTrace();
> 		}
> 	}
> 	private static RuleBase readRule() throws Exception {
> 		Reader source = new InputStreamReader(DroolsTest.class
> 				.getResourceAsStream("/Sample.drl"));
> 		PackageBuilder builder = new PackageBuilder();
> 		builder.addPackageFromDrl(source);
> 		Package pkg = builder.getPackage();
> 		RuleBase ruleBase = RuleBaseFactory.newRuleBase();
> 		ruleBase.addPackage(pkg);
> 		return ruleBase;
> 	}
> 	public static class Parent {
> 	}
> 	public static class Child {
> 		private Parent parent;
> 		public Parent getParent() {
> 			return parent;
> 		}
> 	}
> 	public static class Item {
> 		private Object attachment;
> 		public Object getAttachment() {
> 			return attachment;
> 		}
> 	}
> }
> java.lang.NullPointerException
> 	at org.drools.reteoo.builder.PatternBuilder.createConstraints(PatternBuilder.java:128)
> 	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:72)
> 	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:54)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:136)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:109)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:262)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:333)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:33)
> 	at com.sample.DroolsTest.main(DroolsTest.java:20)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 18:25:50 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 1 Aug 2007 18:25:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1046) Business Object
 returns null due to Shadow Fact, unless declared final
In-Reply-To: <32114281.1185807409476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10401934.1186007150379.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-1046.
------------------------------------

    Resolution: Done

I will close the ticket. If it is still an issue, please reopen.

> Business Object returns null due to Shadow Fact, unless declared final
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1046
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1046
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.MR3,  4.0.0.GA
>         Environment: Windows, X86 based machine
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> SCENARIO
> -----------------
> Define an Object 'BooleanConfiguration'
> public class BooleanConfiguration extends BusinessObject { 
>   String paramName; //with setter and getter
>   Boolean value; //with setter and getter
>   Client client; //with setter and getter -- Client is an object that composes of String clientId;
> }
> *BusinessObject is just a generic Object that maintains a reference to the Assertion List from where it came (Ref. to the container object, Collection).
> Action(s):
> -------------
> 1. initialize the object with a Parameter and Value (Hard code to test) -- Set
> 2. Execute against a Rule:
> When
>    config: BooleanConfiguration(value==true)
> Then
>   //Do something
> end
> EXECUTION NOTES:
> -------------------------------
> 1. I asserted this object and the rule was not executing as I expected.
> 2. I put a break point in the object, and found that it set it correctly but 
> whenenver the rule engine called the get method the vaue of the object was null.
> 3. I traced this the place where it creates shadows in Rete.java.
> I had observed a similar behaviour in version 3.1 or 3.6 (if there was a 3.6).
> it was more prolific then.
> 4. I made the class 'final' (This prevents a shadow from being created), and voila
> my rule worked as expected. 
> Note: None of the other objects needed a final, but had comeplex associations.
> But this particular object does not run, unless declared 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 lists.jboss.org  Wed Aug  1 19:54:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 1 Aug 2007 19:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1040) Multi-pattern
 accumulate support
In-Reply-To: <27334079.1185722987182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30141866.1186012489347.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1040:
----------------------------------

    Fix Version/s: FUTURE

> Multi-pattern accumulate support
> --------------------------------
>
>                 Key: JBRULES-1040
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1040
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> [Edson said there might be already such an issue, but I couldn't find it looking through jira.]
> Something like this should be possible:
>   $multipleQueensHorizontal : Long()
>     from accumulate(
>         $q1 : Queen($id : id, $y : y);
>         Queen(id > $id, y == $y);
>       , count($q1)
>     );

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 19:56:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 1 Aug 2007 19:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31252455.1186012609359.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

So context assist is working, with dslr as the extension. We still need to decide how to handle woolfel's changes. He says this is configurable, so we need to expose this in the IDE configuration, with the default as single sentences.

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Wed Aug  1 23:10:53 2007
From: jira-events at lists.jboss.org (zhang baoquan (JIRA))
Date: Wed, 1 Aug 2007 23:10:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1030) jbpmContext can't
	close
Message-ID: <30881023.1186024253983.JavaMail.jira@cloud.prod.atl2.jboss.com>

jbpmContext can't close
-----------------------

                 Key: JBPM-1030
                 URL: http://jira.jboss.com/jira/browse/JBPM-1030
             Project: JBoss jBPM
          Issue Type: Patch
          Components: Core Engine
    Affects Versions: jBPM jPDL 3.2
         Environment: win2000,tomcat,jbpm3.2,eclipse
            Reporter: zhang baoquan
         Assigned To: Tom Baeyens


Session hsession = jbpmContext.getSession();
try {            
            hsession.save(businessReport);
            ProcessDefinition pd = jbpmContext.getGraphSession().findLatestProcessDefinition("RNDFProcess");
            ProcessInstance pi = pd.createProcessInstance();
            //pi.getContextInstance().setVariable("username", from_username);
            TaskInstance ti = pi.getTaskMgmtInstance().createStartTaskInstance();
            jbpmContext.close();//here is exception
            ti.setVariable("report_id", businessReport.getReportId());
            ti.end();
} catch (Exception e) {
	System.out.println("Unknown error in the SaveGo().");
	e.printStackTrace();
	jbpmContext.setRollbackOnly();
}finally{
            jbpmContext.close();
}
exception:
09:36:53,328 [http8001-Processor22] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
09:36:53,328 [http8001-Processor22] DEBUG JbpmContext : creating org.jbpm.JbpmContext at 1ddf47e
09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceServiceFactory : creating persistence service
09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceService : creating hibernate session
09:36:53,343 [http8001-Processor22] DEBUG DbPersistenceService : beginning hibernate transaction
09:36:53,359 [http8001-Processor22] DEBUG GraphElement : event 'process-start' on 'ProcessDefinition(RNDFProcess)' for 'Token(/)'
09:36:53,359 [http8001-Processor22] WARN  StatefulPersistenceContext : Narrowing proxy to class org.jbpm.graph.node.StartState - this operation breaks ==
09:36:53,375 [http8001-Processor22] DEBUG TaskController : creating task instance variable 'report_id' from process variable 'report_id', value 'null'
09:36:53,375 [http8001-Processor22] DEBUG VariableContainer : create variable 'report_id' in 'TaskInstance[appendForm]' with value 'null'
09:36:53,375 [http8001-Processor22] DEBUG GraphElement : event 'task-create' on 'Task(appendForm)' for 'Token(/)'

09:36:56,203 [http8001-Processor22] DEBUG GraphElement : event 'task-assign' on 'Task(appendForm)' for 'Token(/)'
09:36:56,203 [http8001-Processor22] DEBUG JbpmContext : closing JbpmContext
09:36:56,203 [http8001-Processor22] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 9d478b
09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : committing hibernate transaction
09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate commit failed
org.hibernate.SessionException: Session is closed
	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
	at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:139)
	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:115)
	at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:253)
	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:211)
	at org.jbpm.svc.Services.close(Services.java:222)
	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
	at java.lang.Thread.run(Thread.java:595)
09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : rolling back hibernate transaction
09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate rollback failed
org.hibernate.SessionException: Session is closed
	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
	at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:183)
	at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)
	at org.jbpm.persistence.db.DbPersistenceService.rollback(DbPersistenceService.java:297)
	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:213)
	at org.jbpm.svc.Services.close(Services.java:222)
	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
	at java.lang.Thread.run(Thread.java:595)
09:36:56,203 [http8001-Processor22] WARN  DbPersistenceService : hibernate session was already closed
org.jbpm.persistence.JbpmPersistenceException: hibernate commit failed
	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:216)
	at org.jbpm.svc.Services.close(Services.java:222)
	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
	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 lists.jboss.org  Wed Aug  1 23:15:49 2007
From: jira-events at lists.jboss.org (zhang baoquan (JIRA))
Date: Wed, 1 Aug 2007 23:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1030) session closed
 before jbpmContext close
In-Reply-To: <30881023.1186024253983.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15891702.1186024549511.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1030?page=all ]

zhang baoquan updated JBPM-1030:
--------------------------------

    Summary: session closed before jbpmContext close  (was: jbpmContext can't close)

> session closed before jbpmContext close
> ---------------------------------------
>
>                 Key: JBPM-1030
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1030
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: win2000,tomcat,jbpm3.2,eclipse
>            Reporter: zhang baoquan
>         Assigned To: Tom Baeyens
>
> Session hsession = jbpmContext.getSession();
> try {            
>             hsession.save(businessReport);
>             ProcessDefinition pd = jbpmContext.getGraphSession().findLatestProcessDefinition("RNDFProcess");
>             ProcessInstance pi = pd.createProcessInstance();
>             //pi.getContextInstance().setVariable("username", from_username);
>             TaskInstance ti = pi.getTaskMgmtInstance().createStartTaskInstance();
>             jbpmContext.close();//here is exception
>             ti.setVariable("report_id", businessReport.getReportId());
>             ti.end();
> } catch (Exception e) {
> 	System.out.println("Unknown error in the SaveGo().");
> 	e.printStackTrace();
> 	jbpmContext.setRollbackOnly();
> }finally{
>             jbpmContext.close();
> }
> exception:
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContext : creating org.jbpm.JbpmContext at 1ddf47e
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceServiceFactory : creating persistence service
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceService : creating hibernate session
> 09:36:53,343 [http8001-Processor22] DEBUG DbPersistenceService : beginning hibernate transaction
> 09:36:53,359 [http8001-Processor22] DEBUG GraphElement : event 'process-start' on 'ProcessDefinition(RNDFProcess)' for 'Token(/)'
> 09:36:53,359 [http8001-Processor22] WARN  StatefulPersistenceContext : Narrowing proxy to class org.jbpm.graph.node.StartState - this operation breaks ==
> 09:36:53,375 [http8001-Processor22] DEBUG TaskController : creating task instance variable 'report_id' from process variable 'report_id', value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG VariableContainer : create variable 'report_id' in 'TaskInstance[appendForm]' with value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG GraphElement : event 'task-create' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG GraphElement : event 'task-assign' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG JbpmContext : closing JbpmContext
> 09:36:56,203 [http8001-Processor22] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 9d478b
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : committing hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate commit failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:139)
> 	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:115)
> 	at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:253)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:211)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : rolling back hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate rollback failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:183)
> 	at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)
> 	at org.jbpm.persistence.db.DbPersistenceService.rollback(DbPersistenceService.java:297)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:213)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] WARN  DbPersistenceService : hibernate session was already closed
> org.jbpm.persistence.JbpmPersistenceException: hibernate commit failed
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:216)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	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 lists.jboss.org  Thu Aug  2 01:11:58 2007
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Thu, 2 Aug 2007 01:11:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4589) Upgrade to JSF RI
	1.2_05
Message-ID: <2130135.1186031518237.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade to JSF RI 1.2_05
------------------------

                 Key: JBAS-4589
                 URL: http://jira.jboss.com/jira/browse/JBAS-4589
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.2.GA
            Reporter: Juergen Zimmermann


FYI: I ran my testsuite with JSF 1.2_05 RC1 and hadn't any problems.
The release notes can be found at https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_05/changelog.html

Citation: "Another change which may impact applications is that we've merged all
ServletContextListeners into one listener. In 1.2_04, we had three
separate listeners. If a container wasn't compliant in invoking listeners
defined in a TLD, the developer had to know all three of these. It seemed
to have been a mistake to have so many. The only listener to worry about
at this point is com.sun.faces.config.ConfigureListener."

ConfigureListener is just being used in org/jboss/web/jsf/integration/config/JBossJSFConfigureListener.java
So everything looks 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 lists.jboss.org  Thu Aug  2 01:33:58 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Thu, 2 Aug 2007 01:33:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1046) Business Object
 returns null due to Shadow Fact, unless declared final
In-Reply-To: <32114281.1185807409476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12653746.1186032838505.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1046?page=comments#action_12370812 ] 
            
Arjun Dhar commented on JBRULES-1046:
-------------------------------------

Thanks Edson. Will do some more analysis to ensure I can reproduce the problem for you. There is a lot of code so cant send it all, so will try and find it.

This is not a forum so wont ask a question, but related to you comment "lazy cached", even if it is lazy cached, it cant afford to be that lazy that when an object is called by the Rule, it still returns null. :o) Could that be the problem?

For now we are good. Thank you, appreciate it.

> Business Object returns null due to Shadow Fact, unless declared final
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1046
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1046
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.MR3,  4.0.0.GA
>         Environment: Windows, X86 based machine
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> SCENARIO
> -----------------
> Define an Object 'BooleanConfiguration'
> public class BooleanConfiguration extends BusinessObject { 
>   String paramName; //with setter and getter
>   Boolean value; //with setter and getter
>   Client client; //with setter and getter -- Client is an object that composes of String clientId;
> }
> *BusinessObject is just a generic Object that maintains a reference to the Assertion List from where it came (Ref. to the container object, Collection).
> Action(s):
> -------------
> 1. initialize the object with a Parameter and Value (Hard code to test) -- Set
> 2. Execute against a Rule:
> When
>    config: BooleanConfiguration(value==true)
> Then
>   //Do something
> end
> EXECUTION NOTES:
> -------------------------------
> 1. I asserted this object and the rule was not executing as I expected.
> 2. I put a break point in the object, and found that it set it correctly but 
> whenenver the rule engine called the get method the vaue of the object was null.
> 3. I traced this the place where it creates shadows in Rete.java.
> I had observed a similar behaviour in version 3.1 or 3.6 (if there was a 3.6).
> it was more prolific then.
> 4. I made the class 'final' (This prevents a shadow from being created), and voila
> my rule worked as expected. 
> Note: None of the other objects needed a final, but had comeplex associations.
> But this particular object does not run, unless declared 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 lists.jboss.org  Thu Aug  2 01:39:49 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Thu, 2 Aug 2007 01:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1046) Business Object
 returns null due to Shadow Fact, unless declared final
In-Reply-To: <32114281.1185807409476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16675079.1186033189399.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1046?page=comments#action_12370814 ] 
            
Arjun Dhar commented on JBRULES-1046:
-------------------------------------

sorry, the above was not intended to be a question, Just a thought. Will provide more emperical data to infer the correct problem, if it exists. Thanks again. We can close it, if I find conclusive data, will reopen this bug.

> Business Object returns null due to Shadow Fact, unless declared final
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1046
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1046
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.MR3,  4.0.0.GA
>         Environment: Windows, X86 based machine
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> SCENARIO
> -----------------
> Define an Object 'BooleanConfiguration'
> public class BooleanConfiguration extends BusinessObject { 
>   String paramName; //with setter and getter
>   Boolean value; //with setter and getter
>   Client client; //with setter and getter -- Client is an object that composes of String clientId;
> }
> *BusinessObject is just a generic Object that maintains a reference to the Assertion List from where it came (Ref. to the container object, Collection).
> Action(s):
> -------------
> 1. initialize the object with a Parameter and Value (Hard code to test) -- Set
> 2. Execute against a Rule:
> When
>    config: BooleanConfiguration(value==true)
> Then
>   //Do something
> end
> EXECUTION NOTES:
> -------------------------------
> 1. I asserted this object and the rule was not executing as I expected.
> 2. I put a break point in the object, and found that it set it correctly but 
> whenenver the rule engine called the get method the vaue of the object was null.
> 3. I traced this the place where it creates shadows in Rete.java.
> I had observed a similar behaviour in version 3.1 or 3.6 (if there was a 3.6).
> it was more prolific then.
> 4. I made the class 'final' (This prevents a shadow from being created), and voila
> my rule worked as expected. 
> Note: None of the other objects needed a final, but had comeplex associations.
> But this particular object does not run, unless declared 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 lists.jboss.org  Thu Aug  2 01:41:50 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 01:41:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32023670.1186033310135.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Changes have been made to MicroRemoteClientInvoker.establishLease(), terminateLease(), and org.jboss.remoting.LeasePinger.  

establishLease() has been changed so that the first org.jboss.remoting.Client to call establishLease() and see LeasePinger == null becomes responsible for creating LeasePinger.  All other Client's wait until the first Client informs them that LeasePinger has been created.  Once the job of creating the LeasePinger has been assigned, the Client with that responsibility can exit the synchronization block before doing any network i/o.

The changes to terminateLease() are based on changes to LeasePinger, where the network i/o in removeClient() has been moved to a new method, disconnectClient().  terminateLease() calls removeClient() inside the synchronization block and disconnectClient() outside the synchronization block.

Unit test:  org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Thu Aug  2 01:49:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 01:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1023)
 setStringProperty call
 after a clearProperties call will make getJMSDestination to be null
Message-ID: <27508466.1186033789339.JavaMail.jira@cloud.prod.atl2.jboss.com>

setStringProperty call after a clearProperties call will make getJMSDestination to be null
------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1023
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1023
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR1
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 01:53:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 01:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1023)
 clearProperties call will make getJMSDestination to be null
In-Reply-To: <27508466.1186033789339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11603799.1186034029333.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBMESSAGING-1023:
-----------------------------------------

    Summary: clearProperties call will make getJMSDestination to be null  (was: setStringProperty call after a clearProperties call will make getJMSDestination to be null)

> clearProperties call will make getJMSDestination to be null
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1023
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1023
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:17:53 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:17:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1035)
	StateTransfer200AopTest fails
In-Reply-To: <27241307.1177419690186.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13962128.1186035473850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1035?page=all ]

Jason T. Greene resolved JBCACHE-1035.
--------------------------------------

    Resolution: Done

> StateTransfer200AopTest fails
> -----------------------------
>
>                 Key: JBCACHE-1035
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1035
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Jason T. Greene
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:19:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1125) pojo demo GUI
 doesn't appear (2.0 CR3)
In-Reply-To: <7770922.1183992218930.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16226352.1186035589390.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1125?page=all ]

Jason T. Greene resolved JBCACHE-1125.
--------------------------------------

    Resolution: Done

> pojo demo GUI doesn't appear (2.0 CR3)
> --------------------------------------
>
>                 Key: JBCACHE-1125
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1125
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.CR3
>         Environment: linux, jdk1.5.0_11
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> ./build.sh run.demo.pojocache" doesn't produce a gui window but just hangs after the line:
>      [java] start(): creating the GUI

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:21:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1126) distribution
 example cannot complete (2.0 CR3)
In-Reply-To: <10827053.1183997911833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33481087.1186035709412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1126?page=all ]

Jason T. Greene resolved JBCACHE-1126.
--------------------------------------

    Resolution: Done

> distribution example cannot complete (2.0 CR3)
> ----------------------------------------------
>
>                 Key: JBCACHE-1126
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1126
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.CR3
>         Environment: linux, jdk1.5.0_11
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> All examples fail - some can't compile, some at runtime. These that compile are running and seem to do something (at least eat some CPU cycles) but don't complete within few minutes and through exceptions so I consider them failing. Anything I'm doing wrong? btw I run with ant.
> One problem with a known reason: on loadtime example path is specified with ";" between file names and not ":". To be portable to windows and unix ant path or location element has to 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 lists.jboss.org  Thu Aug  2 02:21:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-846) PojoCache 2.0 key
	features
In-Reply-To: <32822703.1163506601857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9378704.1186035709580.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-846?page=all ]

Jason T. Greene resolved JBCACHE-846.
-------------------------------------

    Resolution: Done

> PojoCache 2.0 key features
> --------------------------
>
>                 Key: JBCACHE-846
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-846
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> Manik, FYI, followings are the key features for PojoCache 2.0. When do the announcement later, please include them in. Thanks! -Ben
> Key PojoCache 2.0 features:
> 1. Supports replicated POJO field as Enum class (JBCACHE-619)
> 2. Option to replicate POJO final field (JBCACHE-839)
> 3. Support JDK5.0 only
> 4. PojoCache provides MBean interface (JBCACHE-783)
> 5. Uses a pojocache-aop.xml for configuration (JBCACHE-780)
> 6. Handle complete rollback of POJO field operation under transaction if needed (JBCACHE-723)
> 7. PojoCache to throw PojoCacheException only runtime exception (JBCACHE-700)
> 8. Interceptor based architecture to allow easy customization (JBCACHE-588)
> 9. PojoCache now uses Cache as a delegate (JBCACHE-673)
> 10. PojoCache event listener (JBCACHE-85)
> 11. During passivation, PojoCache now lazily loads the individual POJO.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:34:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 02:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23141024.1186036489324.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The changes have been applied to the remoting_2_2_0_GA branch.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Thu Aug  2 02:45:50 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 02:45:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8468083.1186037150042.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The changes have been applied to the remoting_2_x branch.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Thu Aug  2 02:54:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1088) problem with
 tests in examples/PojoCache
In-Reply-To: <25815662.1180710008483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5908070.1186037689483.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1088?page=all ]

Jason T. Greene resolved JBCACHE-1088.
--------------------------------------

    Resolution: Done

> problem with tests in examples/PojoCache
> ----------------------------------------
>
>                 Key: JBCACHE-1088
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1088
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.CR2
>            Reporter: Prabhat Jha
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> Running tests in examples/PojoCache has some failures and errors.
> JBossCache-all-2.0.0.CR2/examples/PojoCache/loadtime - Error
>         java.lang.Exception: Don't know how to marshall object of type class examples.Student
> JBossCache-all-2.0.0.CR2/examples/PojoCache/non-annotated - Error
>        javassist.NotFoundException: org.jboss.cache.pojo.observable.SubjectImpl
> JBossCache-all-2.0.0.CR2/examples/PojoCache/passivation - Error
>     ./build.sh compile fails with
>     test.examples.StudentMaintTest.MyCacheListener is not abstract and does not override abstract method nodePassivated(org.jboss.cache.Fqn,boolean,java.util.Map<java.lang.Object,java.lang.Object>) in
>    org.jboss.cache.CacheListener
>     [javac] public class MyCacheListener implements CacheListener
>     [javac] ^
>     [javac] 1 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 lists.jboss.org  Thu Aug  2 02:56:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-172) Strange
 performance problem with LRU
Message-ID: <2766604.1186037809648.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-172?page=all ]

Jason T. Greene updated JBCACHE-172:
------------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

> Strange performance problem with LRU
> ------------------------------------
>
>                 Key: JBCACHE-172
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-172
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>         Environment: Windows XP
> Eclipse 3.1
> JDK50
>            Reporter: Peter Bridge
>         Assigned To: Jason T. Greene
>            Priority: Minor
>             Fix For: 2.1.0.GA
>
>         Attachments: CachePerformanceTest.java, treecacheconfig.xml
>
>
> There seems to be a performance issue when using the LRU option.  With the attaches test, the 100,000 item Get takes 1200ms with LRU and 800ms without any config loaded.  I also noticed the put is slower.  
> get, put, remove
> 2704	1187	625     configured
> 2204	812	625     not configured
> For comparison I used a LinkedHashMap configured as LRU and get these figures:
> 1370	184	172
> Is this an issue with my configuration? Or a problem with how I'm using the cache?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:58:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-472) Release JBoss
	Cache 2.0
Message-ID: <30786047.1186037929443.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Jason T. Greene reassigned JBCACHE-472:
---------------------------------------

    Assignee: Ryan Campbell  (was: Manik Surtani)

JBossCache_2_0_0_GA is taggged and ready for QA

Thanks!

> Release JBoss Cache 2.0
> -----------------------
>
>                 Key: JBCACHE-472
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-472
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Ryan Campbell
>             Fix For: 2.0.0.GA
>
>
> Add all release tasks here (docos, tutorials, dr through to rc, 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 lists.jboss.org  Thu Aug  2 02:58:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 02:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10310885.1186037929572.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The solution is just to break up the synchronization blocks in getCallbackHandler() into two blocks, without the call to the ServerIinvokerCallbackHandler constructor.

The fix has been applied to the remoting_2_2_0_GA branch.

There is no specific unit test.

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 03:12:56 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 03:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently changes listenerId member variable
Message-ID: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>

BisocketClientInvoker.transport() inadvertently changes listenerId member variable
----------------------------------------------------------------------------------

                 Key: JBREM-785
                 URL: http://jira.jboss.com/jira/browse/JBREM-785
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.1.GA, 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on 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 lists.jboss.org  Thu Aug  2 03:40:49 2007
From: jira-events at lists.jboss.org (Peter Bomben (JIRA))
Date: Thu, 2 Aug 2007 03:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
Message-ID: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL-Editor: "Add" button does not work
--------------------------------------

                 Key: JBRULES-1054
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 4.0.1
         Environment: Eclipse-IDE: DSL-Editor
            Reporter: Peter Bomben
         Assigned To: Mark Proctor


Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Thu Aug  2 03:50:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 03:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26536235.1186041049318.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-785:
----------------------------

        Summary: BisocketClientInvoker.transport() inadvertently uses listenerId member variable  (was: BisocketClientInvoker.transport() inadvertently changes listenerId member variable)
    Description: 
org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.

The fix is just to use a stack variable instead of the member variable.

  was:org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.


> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 03:54:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 03:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-785)
 BisocketClientInvoker.transport() inadvertently uses listenerId member
 variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17130811.1186041289329.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The fix has been applied to the remoting_2_2_0_GA branch.

Unit test:  org.jboss.test.remoting.transport.bisocket.listenerID.ListenerIDonStackTestCase.

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 04:22:51 2007
From: jira-events at lists.jboss.org (Takayuki Kaneko (JIRA))
Date: Thu, 2 Aug 2007 04:22:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4590) Add new parameter of
 jnp for connecting each time.
Message-ID: <28892709.1186042971102.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add new parameter of jnp for connecting each time.
--------------------------------------------------

                 Key: JBAS-4590
                 URL: http://jira.jboss.com/jira/browse/JBAS-4590
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Naming
            Reporter: Takayuki Kaneko
         Assigned To: Scott M Stark


I want to add a new parameter on org.jnp.interfaces.NamingContext for connecting 1099 port each time.
Our system needs to connect JNDI each time because there is a load balancer between EJB clients and JBoss servers.

Of course I know the caching server stubs is needed to improve the performance. Our issue might be minority.
So I made a patch that wouldn't change the default behavior about caching.

Could you consider the possibilities of applying this patch? We want to use JBoss Application Server on our system.
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 lists.jboss.org  Thu Aug  2 04:33:49 2007
From: jira-events at lists.jboss.org (Takayuki Kaneko (JIRA))
Date: Thu, 2 Aug 2007 04:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4590) Add new parameter of
 jnp for connecting each time.
In-Reply-To: <28892709.1186042971102.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6736813.1186043629366.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Takayuki Kaneko updated JBAS-4590:
----------------------------------

    Attachment: patch.txt

I changed some methods from static to instance because it is difficult to expand the new feature.
I didn't move these method to right position on source code because it would be difficult to pick out diffs.

> Add new parameter of jnp for connecting each time.
> --------------------------------------------------
>
>                 Key: JBAS-4590
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4590
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>            Reporter: Takayuki Kaneko
>         Assigned To: Scott M Stark
>         Attachments: patch.txt
>
>
> I want to add a new parameter on org.jnp.interfaces.NamingContext for connecting 1099 port each time.
> Our system needs to connect JNDI each time because there is a load balancer between EJB clients and JBoss servers.
> Of course I know the caching server stubs is needed to improve the performance. Our issue might be minority.
> So I made a patch that wouldn't change the default behavior about caching.
> Could you consider the possibilities of applying this patch? We want to use JBoss Application Server on our system.
> 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 lists.jboss.org  Thu Aug  2 06:26:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 2 Aug 2007 06:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1030) session closed before
 jbpmContext close
In-Reply-To: <30881023.1186024253983.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23884588.1186050409395.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1030?page=all ]

Ronald van Kuijk closed JBPM-1030.
----------------------------------

    Resolution: Incomplete Description

you close the context first and then still try to set a taskinstance etc.... looks like a wrong example. So I'm closing this. Reopen with more proof if you think I'm wrong.

> session closed before jbpmContext close
> ---------------------------------------
>
>                 Key: JBPM-1030
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1030
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: win2000,tomcat,jbpm3.2,eclipse
>            Reporter: zhang baoquan
>         Assigned To: Tom Baeyens
>
> Session hsession = jbpmContext.getSession();
> try {            
>             hsession.save(businessReport);
>             ProcessDefinition pd = jbpmContext.getGraphSession().findLatestProcessDefinition("RNDFProcess");
>             ProcessInstance pi = pd.createProcessInstance();
>             //pi.getContextInstance().setVariable("username", from_username);
>             TaskInstance ti = pi.getTaskMgmtInstance().createStartTaskInstance();
>             jbpmContext.close();//here is exception
>             ti.setVariable("report_id", businessReport.getReportId());
>             ti.end();
> } catch (Exception e) {
> 	System.out.println("Unknown error in the SaveGo().");
> 	e.printStackTrace();
> 	jbpmContext.setRollbackOnly();
> }finally{
>             jbpmContext.close();
> }
> exception:
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContext : creating org.jbpm.JbpmContext at 1ddf47e
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceServiceFactory : creating persistence service
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceService : creating hibernate session
> 09:36:53,343 [http8001-Processor22] DEBUG DbPersistenceService : beginning hibernate transaction
> 09:36:53,359 [http8001-Processor22] DEBUG GraphElement : event 'process-start' on 'ProcessDefinition(RNDFProcess)' for 'Token(/)'
> 09:36:53,359 [http8001-Processor22] WARN  StatefulPersistenceContext : Narrowing proxy to class org.jbpm.graph.node.StartState - this operation breaks ==
> 09:36:53,375 [http8001-Processor22] DEBUG TaskController : creating task instance variable 'report_id' from process variable 'report_id', value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG VariableContainer : create variable 'report_id' in 'TaskInstance[appendForm]' with value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG GraphElement : event 'task-create' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG GraphElement : event 'task-assign' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG JbpmContext : closing JbpmContext
> 09:36:56,203 [http8001-Processor22] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 9d478b
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : committing hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate commit failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:139)
> 	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:115)
> 	at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:253)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:211)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : rolling back hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate rollback failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:183)
> 	at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)
> 	at org.jbpm.persistence.db.DbPersistenceService.rollback(DbPersistenceService.java:297)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:213)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] WARN  DbPersistenceService : hibernate session was already closed
> org.jbpm.persistence.JbpmPersistenceException: hibernate commit failed
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:216)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	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 lists.jboss.org  Thu Aug  2 08:07:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:07:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <7418970.1186056469335.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers moved JBIDE-640 to GPD-126:
-------------------------------------

              Project: JBoss jBPM GPD  (was: JBoss Tools)
                  Key: GPD-126  (was: JBIDE-640)
          Component/s:     (was: Seam)
    Affects Version/s: jBPM JPDL Designer 3.1.0.beta2
                           (was: 2.0.0.20070731)

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:09:56 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <1228625.1186056596775.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers moved JBIDE-641 to GPD-127:
-------------------------------------

              Project: JBoss jBPM GPD  (was: JBoss Tools)
                  Key: GPD-127  (was: JBIDE-641)
          Component/s:     (was: jbpm)
    Affects Version/s: jBPM JPDL Designer 3.1.0.beta2
                           (was: 2.0.0.20070731)

> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:11:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:11:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <13225300.1186056709392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers updated GPD-127:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <33315762.1186057009343.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers updated GPD-126:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:36:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 2 Aug 2007 08:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1023) Default local
 interface is not picked up if class is woven with JBoss AOP
In-Reply-To: <27657471.1185982189290.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3978297.1186058209581.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kabir Khan closed EJBTHREE-1023.
--------------------------------

    Resolution: Done

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:57:49 2007
From: jira-events at lists.jboss.org (Kristof Devos (JIRA))
Date: Thu, 2 Aug 2007 08:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1031) Use multiple
	VariableResolvers?
Message-ID: <22519919.1186059469622.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use multiple VariableResolvers?
-------------------------------

                 Key: JBPM-1031
                 URL: http://jira.jboss.com/jira/browse/JBPM-1031
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
    Affects Versions: jBPM 3.1.3
            Reporter: Kristof Devos
         Assigned To: Tom Baeyens
            Priority: Minor


JbpmExpressionValidator uses a static VariableResolver (in case of seam usage it always SeamVariableResolver), in this case it is no longer possible to put variables in the JBPM context instance to resolve in expressions, would it be nice to have multiple  expressionvalidator possible in sorted order to make sure seam context and jbpm context can be used in any 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 lists.jboss.org  Thu Aug  2 09:19:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 2 Aug 2007 09:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
Message-ID: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>

@Local and @Remote on a bean class must have values
---------------------------------------------------

                 Key: EJBTHREE-1025
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.0 GA
            Reporter: Carlo de Wolf
             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD


The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 10:28:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 2 Aug 2007 10:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-450) AOP/MC Proxies do
 not include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23772375.1186064929481.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-450?page=all ]

Kabir Khan updated JBAOP-450:
-----------------------------

    Summary: AOP/MC Proxies do not include original Annotation and Signature attributes  (was: AOP/MC Proxies do not include original annotations)

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.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 lists.jboss.org  Thu Aug  2 11:09:49 2007
From: jira-events at lists.jboss.org (Karsten Dello (JIRA))
Date: Thu, 2 Aug 2007 11:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1032) task-assign-events
 are sometimes fired when group assignment is performed
Message-ID: <3085964.1186067389360.JavaMail.jira@cloud.prod.atl2.jboss.com>

task-assign-events are sometimes fired when group assignment is performed
-------------------------------------------------------------------------

                 Key: JBPM-1032
                 URL: http://jira.jboss.com/jira/browse/JBPM-1032
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: Karsten Dello
         Assigned To: Tom Baeyens


A "task-assingn"-event is sometimes fired, if only group assignment (setting pooledActors) is performed. This always happens when a swimlane is in use which specifies pooled-actors (junit test 1). 

On the other hand, when the  pooled-actors are expressed via an assignment-element as an child element of a task (junit test 2), the event is not fired.

>From my point of view the engine should either:
a) not fire an task-assign-event in case of group assignments at all
b) fire it consequently at all group assignments events
c) fire a different event

Ronald suggested in the forum thread (link above) to introduce a seperate event "task-group-assign" in case a task gets assigned to a group. In my opinion this would be the best solution to this problem.


	public void testTaskAssignIsFiredWithSwimlaneGroupAssignment() {


		ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
				"<process-definition name=\"someprocessxyz\">" +
				
				"  <event type=\"task-assign\">" +
				"    <script>System.out.println(\"task-assign-event fired!\");" +
				"			executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+
				"  </event>"+

				"  <start-state>" +
				"    <transition to='a' />" +
				"  </start-state>" +
				
				"  <swimlane name='swimlane22'>"+
				"    <assignment pooled-actors='jan,nina'/>"+
				"  </swimlane>"+

				"  <task-node name='a'>" +
				"    <task name='sometask' swimlane='swimlane22'/>" +
				"    <transition to='end'/>"+
				"  </task-node>"+
				
				"  <end-state name='end' />" +
				
				"</process-definition>"
		);
		ProcessInstance processInstance = new ProcessInstance(processDefinition);
		Token token = processInstance.getRootToken();
		

		processInstance.signal();
		Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired");
		assertEquals(Boolean.TRUE, o);

		
	}

	public void testTaskAssignIsNOTFiredWithSwimlaneGroupAssignment() {


		ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
				"<process-definition name=\"someprocessxyz\">" +
				
				"  <event type=\"task-assign\">" +
				"    <script>System.out.println(\"task-assign-event fired!\")"+
				"			executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+
				"  </event>"+

				"  <start-state>" +
				"    <transition to='a' />" +
				"  </start-state>" +
				

				"  <task-node name='a'>" +
				"    <task name='sometask'>" +
				"    	<assignment pooled-actors='jan,nina'/>"+
				"    </task>"+
				"    <transition to='end'/>"+
				"  </task-node>"+
				
				"  <end-state name='end' />" +
				
				"</process-definition>"
		);
		ProcessInstance processInstance = new ProcessInstance(processDefinition);
		Token token = processInstance.getRootToken();

		processInstance.signal();
		
		Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired");
		assertEquals(Boolean.TRUE, o);
	}




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:28:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 11:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <3513653.1186068529246.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers resolved GPD-126.
---------------------------

    Resolution: Done

The problem should be fixed now.

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:31:40 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Aug 2007 11:31:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-129) Logical addresses
Message-ID: <392589.1186068700914.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I'm not sure I want to introduce logical addresses. This is regarding
JGRP-129 (logical addresses)  and JGRP-130 (problems with reincarnation).

JGRP-130 is about a member that leaves and rejoins *under the same IP address and port (using bind/start_port)* before failure detection kicks it out. I implemented a fix for this, which won't allow a member into the group that's already in the group. In the above case, with A and B, B would have to wait until the cluster is {A} before it can rejoin.

JGRP-129 is about providing a logical address (possibly host + system time in ms (plus 1 for same system times) for a member, which can be mapped to a physical host/port combo. It would add 4 bytes/address, and I don't see the benefits of this.

The original motivation was that when a member gets shunned, it rejoins under a new identity. Sacha didn't like this and therefore added 'logical addresses' in JBoss, which creates a logical address for a member. So when that member is shunned and rejoins under a *new* JGroups address, it would still keep the *old* JBoss logical address.

I tend to leave it this way, as I don't want to add something which
- adds clutter (Host:26634425614 looks less readable than Host:4536)
- adds 4 bytes / IpAddress
- has some additional lookup in the transport to find the real physical address to which the logical address maps
- needs some ARP-like traffic for establishing local tables which map logical to physical addresses

What do people think ?

> Logical addresses
> -----------------
>
>                 Key: JGRP-129
>                 URL: http://jira.jboss.com/jira/browse/JGRP-129
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough:
> - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper
> - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC
> - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on
> - Network Address Translation: the sender's address might get changed by the NAT
> DESIGN: 
> - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called.
> - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true").
> - The logical addresses must be picked such that they cannot be reused after disconnect()/close().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:32:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Aug 2007 11:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-130) Problems with
	reincarnation
Message-ID: <17351721.1186068769738.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Implementing GMS.reject_join_from_existing_member pretty much fixed this issue. I don't see the need for logical addresses any more. I added a comment to http://jira.jboss.com/jira/browse/JGRP-129. What do people think, is there still a compelling reason we need logical addresses ?

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:57:49 2007
From: jira-events at lists.jboss.org (Michael Wiedmer (JIRA))
Date: Thu, 2 Aug 2007 11:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
Message-ID: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>

Regex-Special characters can not be used in DSLs.
-------------------------------------------------

                 Key: JBRULES-1055
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Java 5
            Reporter: Michael Wiedmer
         Assigned To: Mark Proctor


Up until Drools 3.0.6 one could write DSLs to allow expressions such as

EXAMPLE IS IN [ "one" "two"]

This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.


Here is a (not) working example, using the default sample project:

8<---- regexError.drl -----
package some.test

import com.sample.*;

expander regexError.dsl

rule "Test"
	when
		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
	then 
		LOG "Square Brackets will not work."
end
8<---- regexError.dsl -----
[consequence][]LOG {msg}=System.out.println({msg});
[condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
8<---- DroolsTest.javal -----
package com.sample;

import java.io.InputStreamReader;
import java.io.Reader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class DroolsTest {

    public static final void main(String[] args) {
        try {

            // load up the rulebase
            RuleBase ruleBase = readRule();
            WorkingMemory workingMemory = ruleBase.newStatefulSession();

            // go !
            Message message = new Message();
            message.setMessage("Hello World");
            message.setStatus(Message.HELLO);
            workingMemory.insert(message);
            workingMemory.fireAllRules();

        } catch (Throwable t) {
            t.printStackTrace();
        }
    }

    private static RuleBase readRule() throws Exception {
        Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));

        Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
        PackageBuilder builder = new PackageBuilder();

        builder.addPackageFromDrl(source, dsl);

        Package pkg = builder.getPackage();

        RuleBase ruleBase = RuleBaseFactory.newRuleBase();
        ruleBase.addPackage(pkg);
        return ruleBase;
    }
}


If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:

org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
	at org.drools.rule.Package.checkValidity(Package.java:408)
	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
	at com.sample.DroolsTest.main(DroolsTest.java:18)

It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:59:49 2007
From: jira-events at lists.jboss.org (Michael Wiedmer (JIRA))
Date: Thu, 2 Aug 2007 11:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24072520.1186070389682.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Wiedmer updated JBRULES-1055:
-------------------------------------

    Workaround Description: Users could replace the square brackets with other characters, e.g. the angle brackets. I do not want to be the one who has to bring it to the users to use a new syntax, though.  (was: Users could replace the square brackets with other characters, e.g. the angle brackets.)

> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Mark Proctor
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 12:17:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 12:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <29046442.1186071469231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers resolved GPD-127.
---------------------------

    Resolution: Done

> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 13:07:03 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 2 Aug 2007 13:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-450) AOP/MC Proxies do
 not include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29439629.1186074423449.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Awaiting reply from Chiba about possible problemin javassist

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.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 lists.jboss.org  Thu Aug  2 14:02:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 14:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1023)
 clearProperties call will make getJMSDestination to be null
In-Reply-To: <27508466.1186033789339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18642412.1186077769432.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1023.
----------------------------------------

    Resolution: Done

> clearProperties call will make getJMSDestination to be null
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1023
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1023
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 16:46:54 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Thu, 2 Aug 2007 16:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-274) wsdl service
 generator: eliminate reliance on transitive imports
Message-ID: <19592587.1186087614143.JavaMail.jira@cloud.prod.atl2.jboss.com>

wsdl service generator: eliminate reliance on transitive imports
----------------------------------------------------------------

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


PROBLEM Consider the following network of WSDL documents.

<definitions name="d1" targetNamespace="ns1">
 <import namespace="ns2" location="d2" />
 <binding name="b" type="ns3:pt" />
</definitions>

<definitions name="d2" targetNamespace="ns2">
 <import namespace="ns3" location="d3" />
 <partnerLinkType name="plt">
  <role portType="ns3:pt" />
 </partnerLinkType>
</definitions>

<definitions name="d3" targetNamespace="ns3">
 <portType name="pt" />
</definitions>

ns2:plt is able to resolve the reference tons3:pt, but ns1:b is not. The import element in d1 is not scanned because the binding refers to a port type in namespace ns3 and the import namespace URI is ns2. 

jBPM BPEL is able to resolve such transitive references, but products like the Eclipse BPEL designer and JBossWS are not. 

PROPOSAL While generating d1, create a direct import for d3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 16:54:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Thu, 2 Aug 2007 16:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5555246.1186088089385.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12370936 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

Koen,

I started working with the updated code and am having issues with the priorities. i had defined all of the priorities within my product to be the same - for example, all of my nodes had a priority of -99 as i didnt expect to have to break ties within the product. I'd prefer to allow two nodes to have the same priority. otherwise i have to generate a different priority for each of my nodes - its possible but more work to maintain...

otherwise it is working well so far. i will do more testing over the next week.


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 16:58:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 2 Aug 2007 16:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-998) enable removal of
	EJB3 Timers
In-Reply-To: <27446369.1183052877624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27068798.1186088329372.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste closed EJBTHREE-998.
------------------------------------

    Resolution: Cannot Reproduce Bug

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


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 17:08:59 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 2 Aug 2007 17:08:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
Message-ID: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>

Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
---------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1056
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows
            Reporter: Ming Jin
         Assigned To: Mark Proctor


I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
 
Added 20 packages to rulebase in 0:00:0.15
Added 20 packages to rulebase in 0:00:0.21
Added 20 packages to rulebase in 0:00:0.21
Added 20 packages to rulebase in 0:00:0.301
Added 20 packages to rulebase in 0:00:0.18
Added 20 packages to rulebase 5 times in 0:00:1.051
 
Added 50 packages to rulebase in 0:00:0.17
Added 50 packages to rulebase in 0:00:1.422
Added 50 packages to rulebase in 0:00:1.252
Added 50 packages to rulebase in 0:00:1.322
Added 50 packages to rulebase in 0:00:1.331
Added 50 packages to rulebase 5 times in 0:00:5.497
 
Added 100 packages to rulebase in 0:00:0.19
Added 100 packages to rulebase in 0:00:5.278
Added 100 packages to rulebase in 0:00:5.297
Added 100 packages to rulebase in 0:00:5.228
Added 100 packages to rulebase in 0:00:5.327
Added 100 packages to rulebase 5 times in 0:00:21.32
 
Added 200 packages to rulebase in 0:00:0.22
Added 200 packages to rulebase in 0:00:21.691
Added 200 packages to rulebase in 0:00:21.481
Added 200 packages to rulebase in 0:00:21.642
Added 200 packages to rulebase in 0:00:21.341
Added 200 packages to rulebase 5 times in 0:01:26.385
 
As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.

The following test program would demonstrate the problem:
import java.util.List;
import java.util.ArrayList;
import java.util.Random;
import java.io.StringReader;
import java.io.IOException;

import org.drools.rule.Package;
import org.drools.compiler.PackageBuilder;
import org.drools.compiler.DroolsParserException;
import org.drools.RuleBase;
import org.drools.RuleBaseFactory;

/**
 * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
 * Settings | File Templates.
 */
public class TestDrools {
  private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
  private static final String DRL_TEMPLATE  =
          "package testpackage\n" +
          "import test.TestObject\n"+
          "rule \"testrule_$1\"\n" +
          "  when\n" +
          "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
          "  then\n" +
          "    h.setResult(\"$4\");\n" +
          "end";
  private int count;

  public TestDrools(int count) {
    this.count  = count;
  }

  public void run() throws Exception {
    List<String>  drls  = generateDrls();
    List<Package> pkgs  = generatePackages(drls);

    for (int i = 0; i < 3; i++) {
      addPackages(pkgs, i+1);
    }
  }

  private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
    long     time  = System.currentTimeMillis();
    RuleBase rb  = RuleBaseFactory.newRuleBase();
    for (Package pkg : pkgs)
      rb.addPackage(pkg);
    System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
                       (System.currentTimeMillis()-time)/1000.0+" seconds");
    return rb;
  }

  private List<String> generateDrls() {
    List<String>  list  = new ArrayList<String>(count);
    for (int i = 0; i < count; i++) {
      list.add(getDrl(i));
    }
    return list;
  }

  private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
    List<Package> list  = new ArrayList<Package>(drls.size());
    for (String drl : drls) {
      PackageBuilder  builder = new PackageBuilder();
      builder.addPackageFromDrl(new StringReader(drl));
      list.add(builder.getPackage());
    }
    return list;
  }

  private String getDrl(int seed) {
    String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));

    drl = drl.replace("$2", getRandomString());
    drl = drl.replace("$3", getRandomString());
    return drl.replace("$4", getRandomString());
  }

  private Random  rand  = new Random();

  private String getRandomString() {
    StringBuilder sb  = new StringBuilder();

    for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
      sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
    return sb.toString();
  }

  public static void main(String[] argv) {
    if (argv.length > 0) {
      try {
        new TestDrools(Integer.parseInt(argv[0])).run();
      }
      catch (Exception ex) {
        ex.printStackTrace();
      }
    }
    else
      System.out.println("Usage: TestDrool [# of packages]");
  }
}

package test;
/**
 * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
 * Settings | File Templates.
 */
public class TestObject {
  private String  value1;
  private String  value2;
  private String  result;

  public String getValue1()             { return value1; }
  public void setValue1(String value1)  { this.value1 = value1; }

  public String getValue2()             { return value2; }
  public void setValue2(String value2)  { this.value2 = value2; }

  public String getResult()             { return result; }
  public void setResult(String result)  { this.result = 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 lists.jboss.org  Thu Aug  2 17:10:49 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 2 Aug 2007 17:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8223704.1186089049347.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ming Jin updated JBRULES-1056:
------------------------------

    Attachment: testdrools.zip

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Thu Aug  2 18:55:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 18:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4591) Create a generic way
 to createDestinations on MDB Container
Message-ID: <32782847.1186095349327.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a generic way to createDestinations on MDB Container
-----------------------------------------------------------

                 Key: JBAS-4591
                 URL: http://jira.jboss.com/jira/browse/JBAS-4591
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JB5-Messaging
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.4.0.CR1


We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ.

The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods.


Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName))

or

createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 19:43:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 2 Aug 2007 19:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-942) support
 RemoteBindings annotations from ejb3-interceptors-aop.xml
In-Reply-To: <32737832.1176490394682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32016073.1186098229465.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste closed EJBTHREE-942.
------------------------------------

    Fix Version/s: AS 4.2.2.GA
       Resolution: Done

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 20:04:53 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 2 Aug 2007 20:04:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-878) correct ejb3
 testsuite so that all "expected" failures do not ... well ... fail
In-Reply-To: <2941304.1171493610200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23797928.1186099493295.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste closed EJBTHREE-878.
------------------------------------

    Resolution: Out of Date

> correct ejb3 testsuite so that all "expected" failures do not ... well ... fail
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-878
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-878
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.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 lists.jboss.org  Fri Aug  3 03:36:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1620) location on
 signoOut method is ignored
Message-ID: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>

location on signoOut method is ignored
--------------------------------------

                 Key: JBPORTAL-1620
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final
            Reporter: Thomas Heute
         Assigned To: Thomas Heute
             Fix For: 2.6.2 Final


When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:36:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18915848.1186126609809.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Summary: location on signOut method is ignored  (was: location on signoOut method is ignored)

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:46:54 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1514079.1186127214051.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1620.
------------------------------------

    Resolution: Done

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:46:54 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4640968.1186127214179.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Fix Version/s: 2.8 Final

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:46:54 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <296351.1186127214476.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Fix Version/s:     (was: 2.8 Final)

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:06:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 04:06:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32558114.1186128409776.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Attachment: portal-core-lib.jar

Patched jar

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:37:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 3 Aug 2007 04:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26727632.1186130269363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12370982 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

I don't understand. What are the exact issues you have? Why do you have to give different priorities to the nodes?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:46:40 2007
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 3 Aug 2007 04:46:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <19847696.1186130800262.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-681?page=comments#action_12370983 ] 
            
Bernd Ruecker commented on JBPM-681:
------------------------------------

I like the proposed solution from "nlebas" in the forum:

---
Simply replacing :
list name="exceptionHandlers" cascade="all"
by :
list name="exceptionHandlers" cascade="all" lazy="false" 

in all hibernate mapping files (*.hbm.xml) seem to have solved the problem for me.
I can't figure out why an exception handler should be lazy-loaded anyway. It seems so unsafe... 
---

Also I think it should not be a performance problem, the most projects I now don't you a lot of exception handlers.

I changed it on my machine, Tom, what do you think, commit it?


> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:57:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 04:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-130) Problems with
	reincarnation
Message-ID: <647329.1186131421425.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-130.
---------------------------

    Resolution: Done

Rejecting a new member who wants to join under the identity of an existing member solves the reincarnation issue

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:05:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 3 Aug 2007 05:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <11676832.1186131949412.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-681?page=comments#action_12370987 ] 
            
Ronald van Kuijk commented on JBPM-681:
---------------------------------------

Bernd, Issues that do not have a 'fix version' tend to fall of the radar (unless many people vote for it). So either assign a 'fix version' which you think is reasonable and have Tom or any other person change this or have many people vote for it. 

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:08:04 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 3 Aug 2007 05:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <1895009.1186132084494.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-681?page=comments#action_12370988 ] 
            
Ronald van Kuijk commented on JBPM-681:
---------------------------------------

Or indeed commit it (but still assign a fix version to it so it will be in the releasenotes)

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:09:49 2007
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 3 Aug 2007 05:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <30113935.1186132189562.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-681?page=all ]

Bernd Ruecker updated JBPM-681:
-------------------------------

    Fix Version/s: jBPM jPDL 3.2.2

No problem, assigned it and comitted it

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM jPDL 3.2.2
>
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:09:49 2007
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 3 Aug 2007 05:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <24439302.1186132190009.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-681?page=all ]

Bernd Ruecker resolved JBPM-681.
--------------------------------

    Resolution: Done

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM jPDL 3.2.2
>
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:19:04 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-129) Logical addresses
Message-ID: <23800726.1186132744505.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

With respect to shunning: a shunned member leaves the cluster and rejoins under a new address. So, although it is the same process, the address changes.

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:19:04 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-129) Logical addresses
Message-ID: <1111272.1186132744638.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-129:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Moved to 2.x, so we can revisit the need for logical addresses. My guess is this issue will get closed in 2.x though, unless someone brings forward a compelling reason to implement logical addresses

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:22:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 05:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-408) Expose classes,
 attributes and
 operations via @ManagedResource, @ManagedAttribute and @ManagedOperation
In-Reply-To: <745914.1168605592586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2002603.1186132969321.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-408:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Moved to 2.x. JMX 7 (part of Java 7) includes this feature, so we can use it out of the box in a later version of JGroups, allowing us to remove the parallel JMX class/interface hierarchy

> Expose classes, attributes and operations via @ManagedResource, @ManagedAttribute and @ManagedOperation
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-408
>                 URL: http://jira.jboss.com/jira/browse/JGRP-408
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> We should be able to simply make an object expose management information by annotating it. 
> Input: annotations and classes
> Output: classes which are registered with the platform MBeanServer at runtime using an API (which is also provided). This API
> uses the annotations and reflection to create DynamicMBeans (or MXBeans ?) which are then registered with the MBeanServer.
> Example:
> @ManagedResource(objectName="jgroups:type=protocol;name=UDP")
> public class UDP extends Protocol {
>   @ManagedAttribute(name="Sent", descr="Number of bytes sent")
>   long sent_msgs=0; // generates a 'public long getSent()' getter, *no* setter !
>   @ManagedOperation(description="Prints statistics over the last N seconds")
>   @Parameters({@Parameter(name="timeframe", description="Number of milliseconds (0 for all stats)")})
>   public String printStats(long timeframe)  {
>      // implement;
>   }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 06:03:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 3 Aug 2007 06:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-430)
 ConcurrentModificationException in
 JoinpointSimpleClassifier.classifyJoinpoint
In-Reply-To: <14240559.1182869818277.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28683239.1186135429949.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-430?page=all ]

Kabir Khan closed JBAOP-430.
----------------------------

    Resolution: Done

> ConcurrentModificationException in JoinpointSimpleClassifier.classifyJoinpoint
> ------------------------------------------------------------------------------
>
>                 Key: JBAOP-430
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-430
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.5.GA
>         Environment: JBossAS 4.2.0.GA
> Sun JDK 1.5.0_11 (build 1.5.0_11-b03)
>            Reporter: Bart Vanhaute
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta, 1.5.6.GA
>
>
> With Load time weaving enabled, a ConcurrentModificationException is printed out in the jboss log output (probably a e.printStackTrace() somewhere). 
> Luckily, the code that I want AOP interceptors applied to is indeed woven. So this is not a big issue for me (at the moment).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 07:09:49 2007
From: jira-events at lists.jboss.org (Nishant Jain (JIRA))
Date: Fri, 3 Aug 2007 07:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1159) Issue while using
 "JBossTransactionManagerLookup" as a
 TransactionManagerLookupClass in JBOSS CACHE
Message-ID: <13577806.1186139389501.JavaMail.jira@cloud.prod.atl2.jboss.com>

Issue while using "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in JBOSS CACHE
---------------------------------------------------------------------------------------------------

                 Key: JBCACHE-1159
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1159
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 1.4.1.SP3
            Reporter: Nishant Jain
         Assigned To: Manik Surtani


We are facing the following error while switching from  "DummyTransactionManagerLookup"   to "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in the configuration file (treecache-config.xml) . Could someone help us out in this?


15:15:06,541 ERROR [JBossCacheManager] JBossCacheService to Tomcat clustering not found
15:15:06,541 ERROR [TomcatDeployer] Failed to setup clustering, clustering disabled
15:15:07,634 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManager is null
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3627)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3608)
15:15:07,634 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.getFromCache(TreeCacheProviderImpl.java:105)
15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCitiesFromCache(CitiesCacheManager.java:52)
15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:39)
15:15:07,634 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
15:15:07,634 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
ava:322)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
ntroller.java:262)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
3)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
erAdapter.java:44)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
:107)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
va:72)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
ationFilter.java:195)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
15:15:07,634 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
38)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
l.java:744)
15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
15:15:07,634 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
15:15:07,634 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
15:15:07,634 INFO  [STDOUT]     ... 56 more
15:15:07,681 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManage
r is null
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.put(TreeCache.java:3833)
15:15:07,681 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.addToCache(TreeCacheProviderImpl.java:75)
15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.putCitiesInCache(CitiesCacheManager.java:72)
15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:42)
15:15:07,681 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
15:15:07,681 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
ava:322)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
ntroller.java:262)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
3)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
erAdapter.java:44)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
:107)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
va:72)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
ationFilter.java:195)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
15:15:07,681 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
38)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
l.java:744)
15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
15:15:07,681 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
15:15:07,681 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
15:15:07,681 INFO  [STDOUT]     ... 55 more
15:15:07,899 INFO  [ResourceBundleThemeSource] Theme created: name 'theme', basename [theme]
15:15:07,899 INFO  [ExpressionEvaluationUtils] Using JSP 2.0 ExpressionEvaluator
15:15:56,871 INFO  [Server] Runtime shutdown hook called, forceHalt: true
15:15:56,871 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 07:18:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 3 Aug 2007 07:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1057) properties
 keyword list is missing memberof
Message-ID: <11968073.1186139929349.JavaMail.jira@cloud.prod.atl2.jboss.com>

properties keyword list is missing memberof
-------------------------------------------

                 Key: JBRULES-1057
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1057
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


Can you liaise with Edson, make sure all the correct properties are in syntax highlighting and auto completion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 08:19:50 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Fri, 3 Aug 2007 08:19:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2958226.1186143590016.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tobias Roth reopened JBPORTAL-1592:
-----------------------------------

             
Maybe I am misunderstanding something, but I still think there is a bug around. The filter you posted works and all, but in a real-world scenario, that's not what one would use for a filter. The filter is constructed by the code, one would not directly add LastName, FirstName for a filter, or only that specific user would be found.

If you look at the log snippets I pasted in a previous post, here is what happens: The user enters his credentials in the login box. The code finds the record for that user, and from that record, it takes the DN. From that DN (which may contain a comma), it constructs the search filter to search for roles. Now, if the DN does contain a comma, no roles are found, because the code does not escape the comma correctly. There is no way I can fix this by adapting the filters in my config, or am I missing something? 

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Fri Aug  3 09:27:57 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 09:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29121481.1186147677104.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-510:
--------------------------

    Description: 
NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.

The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 

If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.

When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.

OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.

RESULT: message retransmission is more dynamic:
- Retransmit timeout is *per sender*
- On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
- On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

  was:
NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.

The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 

If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached.

When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.

OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.

RESULT: message retransmission is more dynamic:
- Retransmit timeout is *per sender*
- On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
- On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic


> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 09:32:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Fri, 3 Aug 2007 09:32:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1159) Issue while using
 "JBossTransactionManagerLookup" as a
 TransactionManagerLookupClass in JBOSS CACHE
In-Reply-To: <13577806.1186139389501.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10805428.1186147970093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1159?page=all ]

Manik Surtani closed JBCACHE-1159.
----------------------------------

    Resolution: Rejected

Please don't create JIRA issues until we have confirmed that it is in fact a bug on the forums.

> Issue while using "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in JBOSS CACHE
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1159
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1159
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.1.SP3
>            Reporter: Nishant Jain
>         Assigned To: Manik Surtani
>
> We are facing the following error while switching from  "DummyTransactionManagerLookup"   to "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in the configuration file (treecache-config.xml) . Could someone help us out in this?
> 15:15:06,541 ERROR [JBossCacheManager] JBossCacheService to Tomcat clustering not found
> 15:15:06,541 ERROR [TomcatDeployer] Failed to setup clustering, clustering disabled
> 15:15:07,634 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManager is null
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3627)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3608)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.getFromCache(TreeCacheProviderImpl.java:105)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCitiesFromCache(CitiesCacheManager.java:52)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:39)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
> ava:322)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
> ntroller.java:262)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
> 3)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
> erAdapter.java:44)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
> 15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
> :107)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
> va:72)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
> ationFilter.java:195)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
> 38)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
> )
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
> l.java:744)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 15:15:07,634 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
> 15:15:07,634 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
> 15:15:07,634 INFO  [STDOUT]     ... 56 more
> 15:15:07,681 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManage
> r is null
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.put(TreeCache.java:3833)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.addToCache(TreeCacheProviderImpl.java:75)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.putCitiesInCache(CitiesCacheManager.java:72)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:42)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
> ava:322)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
> ntroller.java:262)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
> 3)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
> erAdapter.java:44)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
> 15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
> :107)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
> va:72)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
> ationFilter.java:195)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
> 38)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
> )
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
> l.java:744)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 15:15:07,681 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
> 15:15:07,681 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
> 15:15:07,681 INFO  [STDOUT]     ... 55 more
> 15:15:07,899 INFO  [ResourceBundleThemeSource] Theme created: name 'theme', basename [theme]
> 15:15:07,899 INFO  [ExpressionEvaluationUtils] Using JSP 2.0 ExpressionEvaluator
> 15:15:56,871 INFO  [Server] Runtime shutdown hook called, forceHalt: true
> 15:15:56,871 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 09:56:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Fri, 3 Aug 2007 09:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7561405.1186149409366.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371016 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

i have several different node (semantic not xml) types and when i gave them the same priority, they all used the same mapper. the other mappers dont look like theyre getting called. when i change the priority it looks like they get called.

here are a couple of elements that interfere with each other:

      <mapping
            adapterClass="com.nexusbpm.editor.xml.EmailSenderNodeDomAdapter"
            id="org.jbpm.gd.jpdl.emailSenderNode"
            mapperClass="com.nexusbpm.editor.xml.EmailSenderNodeDomMapper"
            mapperClassPriority="-98"
            semanticElement="org.jbpm.gd.jpdl.emailSenderNode"
            xmlElement="node"/>
      <mapping
            adapterClass="com.nexusbpm.editor.xml.RNodeDomAdapter"
            id="org.jbpm.gd.jpdl.rNode"
            mapperClass="com.nexusbpm.editor.xml.RNodeDomMapper"
            mapperClassPriority="-97"
            semanticElement="org.jbpm.gd.jpdl.rNode"
            xmlElement="node"/>

if i put the two elements at the same priority only one gets identified.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 10:24:49 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 3 Aug 2007 10:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4591) Create a generic
 way to createDestinations on MDB Container
In-Reply-To: <32782847.1186095349327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <659284.1186151089537.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4591?page=comments#action_12371018 ] 
            
Adrian Brock commented on JBAS-4591:
------------------------------------

Were is this the discussion thread for this?

If you do it, don't change the MDB to enable this by default.

I deprecated this whole feature in JBoss4 and disabled in JBoss5.
Not because it is JBossMQ specific but because it leads to broken behaviour.

See where this has been discussed it before in the JCA and EJB design forums for why this is a bad idea!



> Create a generic way to createDestinations on MDB Container
> -----------------------------------------------------------
>
>                 Key: JBAS-4591
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4591
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JB5-Messaging
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.4.0.CR1
>
>
> We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ.
> The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods.
> Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName))
> or
> createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:13:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 3 Aug 2007 11:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4591) Create a generic way
 to createDestinations on MDB Container
In-Reply-To: <32782847.1186095349327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3904392.1186153981485.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBAS-4591:
----------------------------------

    Fix Version/s:     (was:  JBossAS-5.0.0.Beta3)

> Create a generic way to createDestinations on MDB Container
> -----------------------------------------------------------
>
>                 Key: JBAS-4591
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4591
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JB5-Messaging
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.4.0.CR1
>
>
> We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ.
> The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods.
> Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName))
> or
> createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:13:02 2007
From: jira-events at lists.jboss.org (Anton Melser (JIRA))
Date: Fri, 3 Aug 2007 11:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-130) Problems with
	reincarnation
Message-ID: <220354.1186153982679.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12371050 ] 
            
Anton Melser commented on JGRP-130:
-----------------------------------

This is resolved...is there a release with the new code in it? Do I need to compile from svn?

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:20:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 11:20:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-130) Problems with
	reincarnation
Message-ID: <26180391.1186154449591.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Yes, to test this, you'll need to check out the code from CVS as described in http://sourceforge.net/cvs/?group_id=6081.

This is in CVS head (will be 2.6)

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:32:49 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 3 Aug 2007 11:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-388) Allow specification
 of the exception for after-throwing and finally bindings
In-Reply-To: <12227475.1176743158464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10545520.1186155169956.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-388?page=all ]

Flavia Rainone updated JBAOP-388:
---------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115234

> Allow specification of the exception for after-throwing and finally bindings
> ----------------------------------------------------------------------------
>
>                 Key: JBAOP-388
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-388
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Flavia Rainone
>         Assigned To: Flavia Rainone
>             Fix For: 2.0.0.beta
>
>
> We need to provide an optional attribute to the throwing/finally tags (and to the corrersponding annotation, if it has already been implemented JBAOP-386), so the user can specify an exception type.
> This task includes updating:
> - advice validation algorithm
> - overloaded advice selection algorithm
> - documentation (tutorial, reference manual, 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 lists.jboss.org  Fri Aug  3 11:35:07 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 3 Aug 2007 11:35:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1035) Deploy sources
 jars on mvn deploy
In-Reply-To: <5448191.1185618355146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20743874.1186155307027.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet resolved JBRULES-1035.
---------------------------------------

    Resolution: Done
      Assignee: Geoffrey De Smet  (was: Mark Proctor)

fixed

> Deploy sources jars on mvn deploy
> ---------------------------------
>
>                 Key: JBRULES-1035
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1035
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 4.0.1
>
>         Attachments: sources.patch
>
>
> Because the maven-source-plugin isn't attached to the default lifecylce, you need to explicitly link it in <plugins>.
> Hope this changes for maven 2.1.
> I also added test-jar sources :)
> In the parent pom I changed this:
>         <plugin>
>           <groupId>org.apache.maven.plugins</groupId>
>           <artifactId>maven-source-plugin</artifactId>
>           <version>2.0.2</version>
> 	        <executions>
> 	          <execution>
> 	            <goals>
> 	              <goal>jar</goal>
> +                     <goal>test-jar</goal>
> 	            </goals>
> 	          </execution>
> 	        </executions>
>         </plugin>
> ...
>     </pluginManagement>
>     <plugins>
> +        <plugin>
> +          <!-- Entry needed to create, install and deploy sources jars -->
> +            <groupId>org.apache.maven.plugins</groupId>
> +            <artifactId>maven-source-plugin</artifactId>
> +        </plugin>
>     </plugins>
>   </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 lists.jboss.org  Fri Aug  3 12:44:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 12:44:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-59) IdentityTrust
	Framework
In-Reply-To: <12983617.1181580311625.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26182340.1186159489511.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-59?page=all ]

Anil Saldhana updated SECURITY-59:
----------------------------------

        Summary: IdentityTrust Framework  (was: TrustManager Interface)
    Component/s: JBossSX

> IdentityTrust Framework
> -----------------------
>
>                 Key: SECURITY-59
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-59
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1.BETA
>
>
> Bring in a Trust Manager Interface reachable from the security context to make trust based decisions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 12:50:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 12:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-59) IdentityTrust
	Framework
In-Reply-To: <12983617.1181580311625.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15808943.1186159849289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-59?page=all ]

Anil Saldhana closed SECURITY-59.
---------------------------------

    Resolution: Done

> IdentityTrust Framework
> -----------------------
>
>                 Key: SECURITY-59
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-59
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1.BETA
>
>
> Bring in a Trust Manager Interface reachable from the security context to make trust based decisions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 13:02:49 2007
From: jira-events at lists.jboss.org (james ahlborn (JIRA))
Date: Fri, 3 Aug 2007 13:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-786) stale sockets can be
 gotten from pool even with current rety logic
Message-ID: <27204054.1186160569605.JavaMail.jira@cloud.prod.atl2.jboss.com>

stale sockets can be gotten from pool even with current rety logic
------------------------------------------------------------------

                 Key: JBREM-786
                 URL: http://jira.jboss.com/jira/browse/JBREM-786
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 1.4.6.GA
            Reporter: james ahlborn


The retry logic in SocketClientInvoker.transport attempts to ensure that the invoker does not get a stale socket on the last attempt by flushing the pool.  however, this only discards any currently unused scokets.  a second invoker could return a stale socket after the flush, causing the first invoker to fail again on the last retry (with an EOFException).  while this seems like an edge case, we can hit it reliably under load with many connections to the same destination.  i've patched this class so that the last call to getConnection will never return a pooled connection.  we never got the EOFException after applying this 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 lists.jboss.org  Fri Aug  3 13:04:49 2007
From: jira-events at lists.jboss.org (james ahlborn (JIRA))
Date: Fri, 3 Aug 2007 13:04:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-786) stale sockets can be
 gotten from pool even with current rety logic
In-Reply-To: <27204054.1186160569605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4564453.1186160689467.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

james ahlborn updated JBREM-786:
--------------------------------

    Attachment: remoting-fixes.txt

> stale sockets can be gotten from pool even with current rety logic
> ------------------------------------------------------------------
>
>                 Key: JBREM-786
>                 URL: http://jira.jboss.com/jira/browse/JBREM-786
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.6.GA
>            Reporter: james ahlborn
>         Attachments: remoting-fixes.txt
>
>
> The retry logic in SocketClientInvoker.transport attempts to ensure that the invoker does not get a stale socket on the last attempt by flushing the pool.  however, this only discards any currently unused scokets.  a second invoker could return a stale socket after the flush, causing the first invoker to fail again on the last retry (with an EOFException).  while this seems like an edge case, we can hit it reliably under load with many connections to the same destination.  i've patched this class so that the last call to getConnection will never return a pooled connection.  we never got the EOFException after applying this 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 lists.jboss.org  Fri Aug  3 14:55:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 14:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4592) NPE in
	ExtendedFormAuthenticator
Message-ID: <18543156.1186167349461.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE in ExtendedFormAuthenticator
--------------------------------

                 Key: JBAS-4592
                 URL: http://jira.jboss.com/jira/browse/JBAS-4592
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security, Web (Tomcat) service
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Anil Saldhana
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.2.2.GA


Forum has 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 lists.jboss.org  Fri Aug  3 16:45:03 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Fri, 3 Aug 2007 16:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29111431.1186173903266.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371105 ] 
            
John Ruud commented on GPD-77:
------------------------------

Koen,

Moving the initialize() call to SemanticElementFactory doesn't seem to work for me, for the following reason:

While initialize() is correctly being invoked when dropping something from my palettte:

Decide(AbstractDecide).initialize() line: 21	
SemanticElementFactory.createById(String) line: 30	
CreationFactory.getNewObject() line: 34	
CreateRequest.getNewObject() line: 73
...

it is also invoked as part of reading the diagram (which is not good as it will reset properties that potentially have been modified):

Decide(AbstractDecide).initialize() line: 21	
SemanticElementFactory.createById(String) line: 30	
ProcessDefinitionDomAdapter(XmlAdapter).createSemanticElementFor(XmlAdapter) line: 476	
ProcessDefinitionDomAdapter.doModelAdd(XmlAdapter) line: 157	
ProcessDefinitionDomAdapter(XmlAdapter).initialize(SemanticElement) line: 462	
ProcessDefinitionDomAdapter.initialize(SemanticElement) line: 94	
XpdlEditor(Editor).getSemanticElement(StructuredTextEditor) line: 163	
XpdlEditor(Editor).initSourcePage() line: 145	
XpdlEditor(Editor).createPages() line: 84	
XpdlEditor(JpdlEditor).createPages() line: 134	
XpdlEditor(MultiPageEditorPart).createPartControl(Composite) line: 276	
EditorReference.createPartHelper() line: 596	
EditorReference.createPart() line: 372
...

Invoking initialize() (or possibly named: initializeNew/initializeFromPalette etc.) in org.jbpm.gd.common.editor.CreationFactory DOES work, as it will not get invoked when reading the diagram:

public Object getNewObject() {
		String notationElementId = NotationMapping.getNotationElementId(elementId);
		NotationElement notationElement = notationElementFactory.create(notationElementId);
		if (notationElement instanceof Node) {
			Dimension dimension = NotationMapping.getInitialDimension(elementId);
			if (dimension != null) {
				Rectangle constraint = ((Node)notationElement).getConstraint();
				constraint.setSize(new Dimension(dimension));
			}
		}
		SemanticElement jpdlElement = semanticElementFactory.createById(elementId);
		jpdlElement.initializeNew(); // I added my code here...
		notationElement.setSemanticElement(jpdlElement);
		return notationElement;
	}

Please let me know if you need more info!

John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Fri Aug  3 17:00:49 2007
From: jira-events at lists.jboss.org (tmullett (JIRA))
Date: Fri, 3 Aug 2007 17:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1033) string_max
 parameterization doesn't work
Message-ID: <19022120.1186174849551.JavaMail.jira@cloud.prod.atl2.jboss.com>

string_max parameterization doesn't work 
-----------------------------------------

                 Key: JBPM-1033
                 URL: http://jira.jboss.com/jira/browse/JBPM-1033
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: WIndows XP, Hibernate 3.2.4.sp1, Java 1.4.2
            Reporter: tmullett
         Assigned To: Tom Baeyens


Fields in the hibernate mapping files declared as type "string_max" should be truncated to the parameterized length. The mapping files do this parameterization with a "length" attribute on the property element. It looks like this (from ActionLog.hbm.xml):

<property name="exception"
              type="string_max"
              column="EXCEPTION_"
              length="4000" />

4000 also happens to be what StringMax will use if it can't find or parse its parameterization. We needed to shorten some fields to fit jBpm into MS SQL Server. When we shortened the length, we noticed that the parameter was being ignored, causing jdbc to blow chunks.  org.jbpm.db.hibernate.StringMax.setParameterValues() always gets a null passed in for it's parameters with this setup. To get it to work , we changed it to 

    <property name="exception" column="EXCEPTION_">
		<type name="string_max">
			<param name="length">1000</param>
		</type>
    </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 lists.jboss.org  Fri Aug  3 17:53:53 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 17:53:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-73) Release Security
	V2.0.1-BETA
Message-ID: <14609963.1186178033997.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release Security V2.0.1-BETA
----------------------------

                 Key: SECURITY-73
                 URL: http://jira.jboss.com/jira/browse/SECURITY-73
             Project: JBoss Security and Identity Management
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
    Affects Versions: 2.0.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1.BETA


Release v2.0.1-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 lists.jboss.org  Fri Aug  3 18:00:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 18:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-74) Policy Management
 Console using JBoss SEAM
Message-ID: <14814510.1186178449283.JavaMail.jira@cloud.prod.atl2.jboss.com>

Policy Management Console using JBoss SEAM
------------------------------------------

                 Key: SECURITY-74
                 URL: http://jira.jboss.com/jira/browse/SECURITY-74
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossXACML-Console
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1


Need for a progressive Policy Management console using JBoss SEAM.  The JAXB2 object model provided with JBoss XACML can be used to construct the policies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 18:14:49 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Fri, 3 Aug 2007 18:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
Message-ID: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
---------------------------------------------------------------------------------------

                 Key: GPD-128
                 URL: http://jira.jboss.com/jira/browse/GPD-128
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
            Reporter: John Ruud
         Assigned To: Koen Aers


I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sat Aug  4 04:54:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Sat, 4 Aug 2007 04:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1033) string_max
 parameterization doesn't work
In-Reply-To: <19022120.1186174849551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23279895.1186217689812.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1033?page=comments#action_12371121 ] 
            
Ronald van Kuijk commented on JBPM-1033:
----------------------------------------

can you find out if this is a hibernate version related issue?

> string_max parameterization doesn't work 
> -----------------------------------------
>
>                 Key: JBPM-1033
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1033
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: WIndows XP, Hibernate 3.2.4.sp1, Java 1.4.2
>            Reporter: tmullett
>         Assigned To: Tom Baeyens
>
> Fields in the hibernate mapping files declared as type "string_max" should be truncated to the parameterized length. The mapping files do this parameterization with a "length" attribute on the property element. It looks like this (from ActionLog.hbm.xml):
> <property name="exception"
>               type="string_max"
>               column="EXCEPTION_"
>               length="4000" />
> 4000 also happens to be what StringMax will use if it can't find or parse its parameterization. We needed to shorten some fields to fit jBpm into MS SQL Server. When we shortened the length, we noticed that the parameter was being ignored, causing jdbc to blow chunks.  org.jbpm.db.hibernate.StringMax.setParameterValues() always gets a null passed in for it's parameters with this setup. To get it to work , we changed it to 
>     <property name="exception" column="EXCEPTION_">
> 		<type name="string_max">
> 			<param name="length">1000</param>
> 		</type>
>     </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 lists.jboss.org  Sat Aug  4 13:54:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sat, 4 Aug 2007 13:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22580987.1186250089404.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371137 ] 
            
Koen Aers commented on GPD-128:
-------------------------------

John,

Can you please attach the error log that Eclipse spit out? I need to figure out the 'certain' conditions ;-)

Regards,
Koen

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sat Aug  4 14:58:57 2007
From: jira-events at lists.jboss.org (Mark McNally (JIRA))
Date: Sat, 4 Aug 2007 14:58:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
Message-ID: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>

nested accessors with Sets - "not contains" is not a valid operator for MVEL
----------------------------------------------------------------------------

                 Key: JBRULES-1058
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Mark McNally
         Assigned To: Mark Proctor


Following does not work:

		rule StateMatch
			when
			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
			then 	
				retract( $ca );
		end
		
		
		public class CandidateAssociation {
			private PatientDetails patientDetails;
			private NurseDetails   nurseDetails;
			private int overlapHours;
		
			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
				super();
				this.patientDetails = patientDetails;
				this.nurseDetails = nurseDetails;
				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
			}
		    [...]
		}
		
		public class NurseDetails {
			private Set stateLicensures = new HashSet();
			[...]
		}
		public class PatientDetails {
			private String state;
			[...]
		}

Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 

Also Noticed that the following workaround did not work:

		rule State
		    dialect "mvel"
			when
		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
			then 	
		  	    retract( $ca );
		end
		
		This produced this Exception:
		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
	        at org.drools.rule.Package.checkValidity(Package.java:408)
	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
	        at [...]



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 15:33:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sat, 4 Aug 2007 15:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9552060.1186256029805.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371138 ] 
            
Koen Aers commented on GPD-77:
------------------------------

It may work in this way, but it doesn't feel right as it blurs the lifecycle of the semantic element. Let me think about this and try to come up with a working solution.

Btw. I infer from your previous comment that you guys are doing xpdl on top of jbpm? Can you elaborate on this? Are you planning to contribute something? 

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sat Aug  4 16:56:10 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 16:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
Message-ID: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move network i/o in BisocketClientInvoker constructor to handleConnect()
------------------------------------------------------------------------

                 Key: JBREM-787
                 URL: http://jira.jboss.com/jira/browse/JBREM-787
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 17:10:59 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 17:10:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32302292.1186261859686.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The fix has been applied to branch remoting_2_2_0_GA.

There is no specific unit test.

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 19:15:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 19:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-784) Use separate maps
 for control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32104538.1186269349459.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

It's possible that the confusion was due to another issue, JBREM-785.  However, there is still the possibility that the confusion could arise during a switch to a new control connection.

The fix has been applied to branch remoting_2_2_0_GA.

Unit test: org.jboss.test.remoting.transport.bisocket.SeparateControlSocketsTestCase.

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 19:30:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 19:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7392303.1186270202661.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-775:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.1.GA
                       2.2.0.SP4_CP02

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.1.SP1, 2.2.0.SP4_CP02
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 19:31:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 19:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29880727.1186270309293.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-767:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.1.GA
                       2.2.1.SP1

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Sat Aug  4 22:42:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 22:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
Message-ID: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>

Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
----------------------------------------------------------------------------------------

                 Key: JBREM-788
                 URL: http://jira.jboss.com/jira/browse/JBREM-788
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.1.GA, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 22:46:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 22:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10747642.1186282009547.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The fix has been applied to branch remoting_2_2_0_GA.

There is no specific unit test.

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 00:16:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 00:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29039707.1186287409472.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

One fix for this issue is to move network i/o from the BisocketClientInvoker constructor to BisocketClientInvoker.handleCconnect() - JBREM-787.

Another fix is to have BisocketClientInvoker.handleDisconnect() wake up any threads waiting in BisocketClientInvoker.createSocket().  

The fix for the latter has been applied to branch remoting_2_2_0_GA.

Unit test: org.jboss.test.remoting.transport.bisocket.CallbackDisconnectTestCase.

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Sun Aug  5 05:19:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sun, 5 Aug 2007 05:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-448) maven-jbossaop-plugin
 cannot use include of classes
In-Reply-To: <32238332.1185615887062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32156960.1186305589485.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-448?page=all ]

Anders Andersen closed JBAOP-448.
---------------------------------

    Resolution: Done

I have tested the fix now.
It works.

I can see if I add the include it only compiles the classes in the include
If I do not add include it tries to compile everything

I suggest that we  added a debug statement

      if(getLog().isDebugEnabled()) {
          getLog().debug("Execute AOPC compiler command: "+cl.toString());
      }

so maven .... -X displayes the call to the command.

> maven-jbossaop-plugin cannot use include of classes
> ---------------------------------------------------
>
>                 Key: JBAOP-448
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-448
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>         Environment: any maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> The ant target 
>       <taskdef
>          name="aopc"
>          classname="org.jboss.aop.ant.AopC"
>          classpathref="jbossaop.task.classpath"/>
> is cabable of including specific classes
> Sample:
>       <aopc compilerclasspathref="aop.classpath" verbose="true">
>          <classpath refid="aopc.classpath"/>
>          <src path="${build.classes}"/>
>          <aoppath path="${build.resources}/portal-wsrp-sar/wsrp-aop.xml"/>
>          <include name="org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class"/>
>       </aopc>
> Sample of what it could look like in maven2
>       <plugin>
>         <groupId>org.jboss.maven.plugins</groupId>
>         <artifactId>maven-jbossaop-plugin</artifactId>
>         <executions>
>           <execution>
>             <phase>process-classes</phase>
>             <configuration>
>               <aoppath>${basedir}/../portal-wsrp-sar/src/main/resources/wsrp-aop.xml</aoppath>
>               <verbose>true</verbose>
>               <includes>
>                 <include>org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class</include>
>               </includes>
>             </configuration>
>             <goals>
>               <goal>compile</goal>
>             </goals>
>           </execution>
>         </executions>
>       </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 lists.jboss.org  Sun Aug  5 05:19:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sun, 5 Aug 2007 05:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-448)
 maven-jbossaop-plugin cannot use include of classes
In-Reply-To: <32238332.1185615887062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2813508.1186305589651.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-448?page=comments#action_12371150 ] 
            
Anders Andersen commented on JBAOP-448:
---------------------------------------

I would like to know where the plugin is maven deployed.

> maven-jbossaop-plugin cannot use include of classes
> ---------------------------------------------------
>
>                 Key: JBAOP-448
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-448
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>         Environment: any maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> The ant target 
>       <taskdef
>          name="aopc"
>          classname="org.jboss.aop.ant.AopC"
>          classpathref="jbossaop.task.classpath"/>
> is cabable of including specific classes
> Sample:
>       <aopc compilerclasspathref="aop.classpath" verbose="true">
>          <classpath refid="aopc.classpath"/>
>          <src path="${build.classes}"/>
>          <aoppath path="${build.resources}/portal-wsrp-sar/wsrp-aop.xml"/>
>          <include name="org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class"/>
>       </aopc>
> Sample of what it could look like in maven2
>       <plugin>
>         <groupId>org.jboss.maven.plugins</groupId>
>         <artifactId>maven-jbossaop-plugin</artifactId>
>         <executions>
>           <execution>
>             <phase>process-classes</phase>
>             <configuration>
>               <aoppath>${basedir}/../portal-wsrp-sar/src/main/resources/wsrp-aop.xml</aoppath>
>               <verbose>true</verbose>
>               <includes>
>                 <include>org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class</include>
>               </includes>
>             </configuration>
>             <goals>
>               <goal>compile</goal>
>             </goals>
>           </execution>
>         </executions>
>       </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 lists.jboss.org  Sun Aug  5 06:27:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sun, 5 Aug 2007 06:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1615) Maven2 poms
 initial version ready for portal
In-Reply-To: <4157740.1185486047091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28331354.1186309669411.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anders Andersen updated JBPORTAL-1615:
--------------------------------------

    Attachment: _maven-08-05.tar.gz

1) AOPC plugin JIRA JBAOP-448 fixed. Meaning path to classes now works without prefix with maven project location
2) wsrp fixed with this
3) core fixed with this
4) samples fully removed from build

> Maven2 poms initial version ready for portal
> --------------------------------------------
>
>                 Key: JBPORTAL-1615
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1615
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>         Environment: unix script used (use unix or cygwin)
>            Reporter: Anders Andersen
>         Attachments: _maven-08-05.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz
>
>          Time Spent: 1 day, 5 hours
>  Remaining Estimate: 0 minutes
>
> The _maven directory will contain a complete maven2 build environment for the jboss portal
> prepare:
>           If you are running windows --> install cygwin and run bash from here
>           1) #install maven2 (2.0.6) or later
>           2) #install the jboss-packaging-maven-plugin
>              svn co https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/jboss-packaging-maven-plugin jboss-packaging-maven-plugin
>              mvn -f jboss-packaging-maven-plugin/pom.xml install
>           3) #install the portal
>              svn co http://anonsvn.jboss.org/repos/portal/trunk jboos-portal
>              cd jboss-portal
>              build/build.sh clean most
>           4) unzip the _maven into jboss-portal
>           5) cd _maven
>              cd _deploy
>              # deploy the third party artifacts that I did not find on the internet
>              # edit the script to meet your settings before running
>              ./third-party-deploy.sh
>           6) #prepare the maven source locations
> usage:       #run script
>              ./_build.sh
> post steps:
>           7) #maven build the jboss 2.6 portal
>              mvn clean install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 13:21:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 13:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25050997.1186334509336.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-765:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.1.GA
                       2.2.0.SP4_CP02

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 14:53:49 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Sun, 5 Aug 2007 14:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1059) Online typos in
	Section 1
Message-ID: <15111425.1186340029389.JavaMail.jira@cloud.prod.atl2.jboss.com>

Online typos in Section 1
-------------------------

                 Key: JBRULES-1059
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1059
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.MR3
         Environment: n/a  - concerns documentation availble for viewing over internet
            Reporter: Dave Dibble
         Assigned To: Mark Proctor
            Priority: Trivial


miscellaneous typos

http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/index.html

Section 1.1
modiied ? modified
Drools will adding ? Drools will be adding

Section 1.2.1
explination ? explanation
layed ? laid
espically ? especially
knowlegde ? knowledge

Section 1.2.4
preceeding ? preceding
its ? it's

Section 1.3.1
shortley ? shortly

Section 1.3.2
conjuntive ? conjunctive
disjuntive ? disjunctive

Section 1.6.1
grammer ? grammar
deployeable ? deployable
PackagBuilder ? PackageBuilder

Section 1.6.4.6
In the shaded box, should 'new List' simply be 'List' ?

Section 1.6.5
legible ? eligible

section 1.6.6.1
managable ? manageable

section 1.6.7
AgendEventListener ? AgendaEventListener






-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Sun Aug  5 16:23:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21331758.1186345429282.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

There is a new configuration parameter, org.jboss.remoting.callback.ServerInvokerCallbackHandler.CALLBACK_TIMEOUT (actual value "callbackTimeout"), which can be used to set the timeout value for server side callback clients.  For callback clients the value associated with CALLBACK_TIMEOUT overrides the value associated with org.jboss.remoting.ServerInvoker.TIMEOUT (actual value "timeout").

There are multiple ways of setting the CALLBACK_TIMEOUT value.  In order of descending priority:

1. it may be put into the metadata map used in the call to org.jboss.remoting.Client.addListener();

2. it may be placed in the server's InvokerLocator;

3. it may be placed in the configuration map passed to the server Connector's constructor.

That is, the value in the metadata map overrides the values in the InvokerLocator and configuration map, and the value in the InvokerLocator overrides the value in the configuration map.

The feature has been implemented in the remoting_2_2_0_GA branch.

Unit tests:  The feature has been tested for the socket and bisocket transports:

    org.jboss.test.remoting.callback.timeout.BisocketCallbackTimeoutTestCase
    org.jboss.test.remoting.callback.timeout.SocketCallbackTimeoutTestCase

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:25:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19173789.1186345549295.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Another fix is to allow a separately configurable timeout value for callback clients (JBREM-765).  That feature has been implemented on the remoting_2_2_0_GA branch.

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Sun Aug  5 16:33:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17687940.1186346029361.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal reopened JBREM-779:
-----------------------------

             

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:33:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13792100.1186346029475.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-779:
----------------------------

        Fix Version/s: 2.4.0.Beta1 (Pinto)
    Affects Version/s: 2.2.0.SP4_CP02
                       2.4.0.Beta1 (Pinto)
                           (was: 2.2.0.SP4)

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:36:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-779) BisocketClientInvoker
 should guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10145035.1186346162103.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal closed JBREM-779.
---------------------------

    Resolution: Done

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:37:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16468669.1186346269364.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-766:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA
                       2.2.0.SP4_CP02

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:47:49 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 5 Aug 2007 16:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-678) Remove spring
	dependency
In-Reply-To: <4908345.1171728569969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8859296.1186346869324.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-678?page=comments#action_12371166 ] 
            
Geoffrey De Smet commented on JBRULES-678:
------------------------------------------

A large part has been done, including removing the use of spring's Resource and spring Log4jConfigurer and InitializingBean in the examples.

Only thing that remains is the use of spring to put together the solver. Although it's easy to replace that with plain old java code, the solver configuration is a better solution.

> Remove spring dependency
> ------------------------
>
>                 Key: JBRULES-678
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-678
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Solver
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>
> Once the configuration xml is extracted this should be a peice of cake

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 17:53:02 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Sun, 5 Aug 2007 17:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1709215.1186350782875.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-128?page=all ]

John Ruud updated GPD-128:
--------------------------


Koen,

My stack trace is included (below). While my own classes are involved in this case, it may hopfully be clear by looking at line 43 of XmlAdapterRegistry why the exception occurs (a TreeSet is added to xmlElementMap, but in line 52 this Set is then attempted casted to an IConfigurationElement)

John

!ENTRY org.eclipse.ui 4 4 2007-08-05 14:16:41.843
!MESSAGE Unhandled event loop exception

!ENTRY org.eclipse.ui 4 0 2007-08-05 14:16:41.890
!MESSAGE java.util.TreeSet cannot be cast to org.eclipse.core.runtime.IConfigurationElement
!STACK 0
java.lang.ClassCastException: java.util.TreeSet cannot be cast to org.eclipse.core.runtime.IConfigurationElement
	at org.jbpm.gd.common.registry.XmlAdapterRegistry.getConfigurationElementByXmlElementName(XmlAdapterRegistry.java:52)
	at com.thrasys.gd.xpdl.model.ModelFactory.getSemanticElementId(ModelFactory.java:53)
	at com.thrasys.gd.xpdl.model.ModelFactory.createByElementId(ModelFactory.java:60)
	at com.thrasys.gd.xpdl.model.ModelFactory.addXNetXml(ModelFactory.java:92)
	at com.thrasys.gd.xpdl.model.Node.initializeNew(Node.java:9)
	at org.jbpm.gd.common.editor.CreationFactory.getNewObject(CreationFactory.java:35)
	at org.eclipse.gef.requests.CreateRequest.getNewObject(CreateRequest.java:73)
	at org.jbpm.gd.common.policy.XYLayoutEditPolicy.initCreateCommand(XYLayoutEditPolicy.java:58)
	at org.jbpm.gd.common.policy.XYLayoutEditPolicy.getCreateCommand(XYLayoutEditPolicy.java:42)
	at org.eclipse.gef.editpolicies.LayoutEditPolicy.getCommand(LayoutEditPolicy.java:199)
	at org.eclipse.gef.editpolicies.ConstrainedLayoutEditPolicy.getCommand(ConstrainedLayoutEditPolicy.java:154)
	at org.eclipse.gef.editparts.AbstractEditPart.getCommand(AbstractEditPart.java:473)
	at org.eclipse.gef.tools.TargetingTool.getCommand(TargetingTool.java:122)
	at org.eclipse.gef.tools.CreationTool.handleMove(CreationTool.java:239)
	at org.eclipse.gef.tools.AbstractTool.mouseMove(AbstractTool.java:1038)
	at org.eclipse.gef.EditDomain.mouseMove(EditDomain.java:248)
	at org.eclipse.gef.ui.parts.DomainEventDispatcher.dispatchMouseMoved(DomainEventDispatcher.java:359)
	at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseMove(LightweightSystem.java:533)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:145)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1930)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:422)
	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(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	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)

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sun Aug  5 17:56:49 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Sun, 5 Aug 2007 17:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24076381.1186351009357.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371169 ] 
            
John Ruud commented on GPD-77:
------------------------------

I've been experimenting with (on and off) adding GD support for "xpdl", which would become a domain specific "extension" of jpdl. Because of its proprietary nature it wouldn't be very useful to the general public. I plan to keep contributing patches and post feature requests that would make it possible/easier to use GD for editing "xpdl",  and this would hopfully also make it easier for other developers to add support for their own dsls. Does this sound like a good approach?

Thanks, John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sun Aug  5 18:13:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sun, 5 Aug 2007 18:13:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18755405.1186352029370.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371170 ] 
            
Koen Aers commented on GPD-77:
------------------------------

xpdl is a public standard so it is definitely not proprietary. 

xpdl support is on the roadmap of our new pvm approach. we are collaborating with the guys from the bonita engine and with the eclipse jwt project to get this going. 

or is this a name clash? 

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sun Aug  5 18:26:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Sun, 5 Aug 2007 18:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29451035.1186352761896.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371171 ] 
            
John Ruud commented on GPD-77:
------------------------------

LOL - it's a name clash (guess I need to come up with something more original)

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sun Aug  5 19:05:49 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 5 Aug 2007 19:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3439170.1186355149492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen reassigned JBAOP-449:
------------------------------------

    Assignee: Stale Pedersen

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Sun Aug  5 19:10:02 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 5 Aug 2007 19:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25614314.1186355402453.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-449?page=comments#action_12371173 ] 
            
Stale Pedersen commented on JBAOP-449:
--------------------------------------

it should work as ant do, eg just add the files in the same element separated by the "File.pathSeparator". - but this isnt very portable and we'll look into it before the release of 2.0.

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Sun Aug  5 19:10:02 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 5 Aug 2007 19:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-447) maven-jbossaop-plugin
 uses wrong location of target/classes
In-Reply-To: <32850547.1185615647354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27611487.1186355402693.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Stale Pedersen closed JBAOP-447.
--------------------------------


> maven-jbossaop-plugin uses wrong location of target/classes
> -----------------------------------------------------------
>
>                 Key: JBAOP-447
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-447
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: unix OSX 10.4.10
> java 1.5
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> the plugin uses target/classes as the location of classes.
> This is wrong when you use mvn -f xxxxx/pom.xml clean process-classes
> class: maven-jbossaop-plugin/src/main/java/org/jboss/maven/plugins/JBossAOPCMojo.java
> code error ****
>       if(isTest())
>          cl.addArguments(new String[] { project.getBuild().getTestOutputDirectory()});
>       else
>          cl.addArguments(new String[] { "target/classes"});
> better code******
>       if(isTest())
>          cl.addArguments(new String[] { project.getBuild().getTestOutputDirectory()});
>       else
>          cl.addArguments(new String[] { project.getBuild().getOutputDirectory()});

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 22:29:49 2007
From: jira-events at lists.jboss.org (christopher barham (JIRA))
Date: Sun, 5 Aug 2007 22:29:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
Message-ID: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unexpected exit with no stack trace or other information
--------------------------------------------------------

                 Key: JBRULES-1060
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
            Reporter: christopher barham
         Assigned To: Mark Proctor


When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.

Garbage.java (fact bean):

package com.sample;

public class Garbage {
    private char id;

    private int someNumber;

    public Garbage(char garbageId, int someNumber) {
        setSomeNumber(someNumber);
        setId(garbageId);
    }

    public char getId() {
        return id;
    }

    public int getSomeNumber() {
        return someNumber;
    }

    public void setId(char id) {
        this.id = id;
    }

    public void setSomeNumber(int someNumber) {
        this.someNumber = someNumber;
    }

    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder();
        sb.append("a Garbage { ");
        sb.append("someNumber= ");
        sb.append(getSomeNumber());
        sb.append(", id= ");
        sb.append(getId());
        sb.append(" }");
        return sb.toString();
    }

}

StrangeExit.Java (Rule Engine startup and fact insertion):

package com.sample;

import java.io.InputStreamReader;
import java.io.Reader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;
import org.drools.event.DebugWorkingMemoryEventListener;
import org.drools.rule.Package;

public class StrangeExit {

    public static final void main(String[] args) {
        try {
            long startTime = System.currentTimeMillis();
            System.out.println("Starting problem at " + new java.util.Date());
            RuleBase ruleBase = readRule();
            WorkingMemory workingMemory = ruleBase.newStatefulSession();

            workingMemory.addEventListener(new DebugWorkingMemoryEventListener());

            assertAllFacts(workingMemory);

            workingMemory.fireAllRules();

            long stopTime = System.currentTimeMillis();
            long runTime = stopTime - startTime;
            System.out.println("Run time (milliseconds): " + runTime);
            System.out.println("Finished problem at " + new java.util.Date());
        } catch (Throwable t) {
            t.printStackTrace();
        }
    }

    private static void assertAllFacts(WorkingMemory workingMemory) {
        for (int i = 1; i <= 3; i++) {
            for (int j = 1; j <= 475; j++) {
                Garbage gar = new Garbage((char)(i + 64), j);
                workingMemory.insert(gar);
            }
        }
    }

    private static RuleBase readRule() throws Exception {
        Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
        PackageBuilder builder = new PackageBuilder();
        builder.addPackageFromDrl(source);
        Package pkg = builder.getPackage();
        RuleBase ruleBase = RuleBaseFactory.newRuleBase();
        ruleBase.addPackage(pkg);
        return ruleBase;
    }
}


The Rule itself:

package com.sample

import com.sample.Garbage;

rule "Weird exit with no stack trace error"
  when
    $garA : Garbage(  )
    $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
  then
    System.out.println("Something is up");
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 lists.jboss.org  Sun Aug  5 22:33:53 2007
From: jira-events at lists.jboss.org (christopher barham (JIRA))
Date: Sun, 5 Aug 2007 22:33:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7850956.1186367633369.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

christopher barham updated JBRULES-1060:
----------------------------------------

    Attachment: strangeExit.zip

Small example demonstrating the exit issue

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Mon Aug  6 00:07:06 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 6 Aug 2007 00:07:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13864174.1186373226943.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Changes have been made to the following:

   - org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket()
   - org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnection()
   - org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection()
   - org.jboss.remoting.transport.socket.ServerThread.run()
   - org.jboss.remoting.transport.socket.SocketServerInvoker.ServerSocketRefresh

The changes have been applied to the remoting_2_2_0_GA branch.

There are no specific unit tests.

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 03:43:49 2007
From: jira-events at lists.jboss.org (Pavel Myshkin (JIRA))
Date: Mon, 6 Aug 2007 03:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1621) "title"
 attribute of "link" tag in jboss-portlet.xml is unhandled
Message-ID: <30538884.1186386229579.JavaMail.jira@cloud.prod.atl2.jboss.com>

"title" attribute of "link" tag in jboss-portlet.xml is unhandled
-----------------------------------------------------------------

                 Key: JBPORTAL-1621
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1621
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: JBoss Portal 2.6.1 GA bundled
            Reporter: Pavel Myshkin


JBOSS-PORTLET.XML
--------------------------------
<!DOCTYPE portlet-app PUBLIC
   "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
   "dtd/jboss-portlet_2_6.dtd">
<portlet-app>
<portlet>
<portlet-name>PortletName</portlet-name>
<header-content>
<!-- main calendar program -->
<link rel="stylesheet" type="text/css" media="all" href="/calendar-win2k-cold-1.css"  title="win2k-cold-1"/>
</header-content>
</portlet>
</portlet-app>

Generates an error :
Caused by: org.xml.sax.SAXException: Attribute "title" must be declared for element type "link". @ *unknown*[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 lists.jboss.org  Mon Aug  6 03:43:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 03:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19327501.1186386229764.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1017?page=comments#action_12371179 ] 
            
Galder Zamarreno commented on EJBTHREE-1017:
--------------------------------------------

What link are you refering to when you say that the link 
is not here? If you're refering to the support case link, it is 
already in the JIRA issue.

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 03:45:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 03:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30863256.1186386349449.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1017?page=comments#action_12371180 ] 
            
Galder Zamarreno commented on EJBTHREE-1017:
--------------------------------------------

or you mean to mark the patch as complete?

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 03:55:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 6 Aug 2007 03:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1621) "title"
 attribute of "link" tag in jboss-portlet.xml is unhandled
In-Reply-To: <30538884.1186386229579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28532855.1186386949289.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1621:
-----------------------------------

          Component/s: Portal Core
        Fix Version/s: 2.6.2 Final
    Affects Version/s: 2.6.1 Final

> "title" attribute of "link" tag in jboss-portlet.xml is unhandled
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-1621
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1621
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>         Environment: JBoss Portal 2.6.1 GA bundled
>            Reporter: Pavel Myshkin
>             Fix For: 2.6.2 Final
>
>
> JBOSS-PORTLET.XML
> --------------------------------
> <!DOCTYPE portlet-app PUBLIC
>    "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
>    "dtd/jboss-portlet_2_6.dtd">
> <portlet-app>
> <portlet>
> <portlet-name>PortletName</portlet-name>
> <header-content>
> <!-- main calendar program -->
> <link rel="stylesheet" type="text/css" media="all" href="/calendar-win2k-cold-1.css"  title="win2k-cold-1"/>
> </header-content>
> </portlet>
> </portlet-app>
> Generates an error :
> Caused by: org.xml.sax.SAXException: Attribute "title" must be declared for element type "link". @ *unknown*[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 lists.jboss.org  Mon Aug  6 04:44:53 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 04:44:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14043696.1186389893765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371181 ] 
            
Koen Aers commented on GPD-77:
------------------------------

ROTFL

Maybe you need to go into the 7-character acromym space to still find something useful in the workflow/BPM space ;-)

As for the problem at hand. Isn't it possible to do use the XmlAdapter.initialze(SemanticElement) method to override the (default) values that were set in the SemanticElement.initialize() method by the values that are specified in the xml? This method was created for this purpose in any case.

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Mon Aug  6 05:21:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 05:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9444772.1186392109360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-128?page=all ]

Koen Aers resolved GPD-128.
---------------------------

    Resolution: Won't Fix

John, 

I forgot to delete the XmlAdapterRegistry.getConfigurationElementByXmlElementName(String) method while implementing GPD-111. In fact you should now use the XmlAdapterRegistry.getConfigurationElementByXmlNode(Node) to obtain the correct configuration element. You can have multiple configurationelements related to the same xml node name. There are still issues with it, but I am working on fixing those. Have a look at GPD-111 and feel free to ask for clarifications.

Regards,
Koen

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Mon Aug  6 06:08:50 2007
From: jira-events at lists.jboss.org (Holger Szillat (JIRA))
Date: Mon, 6 Aug 2007 06:08:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-429) Support for
 external security systems
Message-ID: <27304829.1186394930152.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-429?page=comments#action_12371186 ] 
            
Holger Szillat commented on JBPM-429:
-------------------------------------

I have made the following changes to my source-code of the jBPM v.3.1.4:

protected Delegation readAssignmentDelegation( Element assignmentElement ) {
    Delegation assignmentDelegation = new Delegation();
    String expression = assignmentElement.attributeValue( "expression" );
    String actorId = assignmentElement.attributeValue( "actor-id" );
    String pooledActors = assignmentElement.attributeValue( "pooled-actors" );
    String assignmentClass = assignmentElement.attributeValue( "class" );

    if ( expression != null ) {
      assignmentDelegation.setProcessDefinition( processDefinition );

      if ( assignmentClass != null )
        assignmentDelegation.setClassName( assignmentClass );
      else
        assignmentDelegation
            .setClassName( "org.jbpm.identity.assignment.ExpressionAssignmentHandler" );

      assignmentDelegation.setConfiguration( "<expression>" + expression
          + "</expression>" );

    } else {
      if ( ( actorId != null ) || ( pooledActors != null ) ) {
        assignmentDelegation.setProcessDefinition( processDefinition );
        assignmentDelegation
            .setClassName( "org.jbpm.taskmgmt.assignment.ActorAssignmentHandler" );
        String configuration = "";
        if ( actorId != null ) {
          configuration += "<actorId>" + actorId + "</actorId>";
        }
        if ( pooledActors != null ) {
          configuration += "<pooledActors>" + pooledActors + "</pooledActors>";
        }
        assignmentDelegation.setConfiguration( configuration );

      } else {
        assignmentDelegation.read( assignmentElement, this );
      }
    }
    return assignmentDelegation;
  }


Note, that I simply read the class-element (which is allowed according to the XML-grammar) and only set the "default" handler if the element was not specified.

Maybe it helps...

> 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 lists.jboss.org  Mon Aug  6 06:35:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 06:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17108692.1186396549330.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371189 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

I made a mistake implementing the priority comparator. I think it should work now, can you verify?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 07:27:03 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 07:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-111) Add ability to
 forward and reverse
 map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29543934.1186399623197.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Koen Aers resolved GPD-111.
---------------------------

    Resolution: Done

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 07:53:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 6 Aug 2007 07:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1020)
	java:comp/EJBContext broken
In-Reply-To: <9377492.1185368221039.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28751618.1186401229326.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved EJBTHREE-1020.
-------------------------------------

    Resolution: Done

> java:comp/EJBContext broken
> ---------------------------
>
>                 Key: EJBTHREE-1020
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1020
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> java:comp/EJBContext is bound at semi-random times, which results in broken behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 09:08:59 2007
From: jira-events at lists.jboss.org (Jessica Sant (JIRA))
Date: Mon, 6 Aug 2007 09:08:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8335076.1186405739463.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Jessica Sant resolved EJBTHREE-1017.
------------------------------------

    Resolution: Done

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 09:10:49 2007
From: jira-events at lists.jboss.org (Jessica Sant (JIRA))
Date: Mon, 6 Aug 2007 09:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <930840.1186405849472.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Jessica Sant updated EJBTHREE-1017:
-----------------------------------

    Patch Repository Link: https://network.jboss.com/jbossnetwork/restricted/softwareDetail.html?softwareId=a0430000007j8N6

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 09:23:49 2007
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 6 Aug 2007 09:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1061) jsr94 constants
 wrong package
 builder config constant, same name as rulebase config constant
Message-ID: <28549329.1186406629349.JavaMail.jira@cloud.prod.atl2.jboss.com>

jsr94 constants wrong package builder config constant, same name as rulebase config constant
--------------------------------------------------------------------------------------------

                 Key: JBRULES-1061
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1061
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JSR94
    Affects Versions:  4.0.0.GA
            Reporter: Juergen none
         Assigned To: Mark Proctor
            Priority: Minor


org.drools.jsr94.rules.Constants, line 49f:

    /** <code>RuleExecutionSet</code> rulebase config constant. */
    public static final String RES_RULEBASE_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";
    
    /** <code>RuleExecutionSet</code> package builder config constant. */
    public static final String RES_PACKAGEBUILDER_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";    

Packagebuilder config constant is same as rulebase config constant. yields classcast exception if a rulebase config is set:

Caused by: java.lang.ClassCastException: org.drools.RuleBaseConfiguration
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:124)
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 10:10:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 6 Aug 2007 10:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23959902.1186409449299.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf reassigned EJBTHREE-1025:
---------------------------------------

    Assignee: Carlo de Wolf

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 10:54:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 10:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-759) Create a set of
 deadlock-detecting unit tests
In-Reply-To: <24324626.1157382703762.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7938961.1186412089504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-759?page=all ]

Galder Zamarreno reassigned JBCACHE-759:
----------------------------------------

    Assignee: Galder Zamarreno  (was: Manik Surtani)

> 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.GA
>            Reporter: Manik Surtani
>         Assigned To: Galder Zamarreno
>             Fix For: 2.1.0.GA
>
>
> 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 lists.jboss.org  Mon Aug  6 12:13:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 12:13:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1122) Be able to define
 regions using regular expressions
In-Reply-To: <23692257.1183725292844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25520418.1186416829433.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1122?page=all ]

Galder Zamarreno updated JBCACHE-1122:
--------------------------------------

    Priority: Minor  (was: Major)

> Be able to define regions using regular expressions
> ---------------------------------------------------
>
>                 Key: JBCACHE-1122
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1122
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 3.0.0
>
>
> Particularly useful once we have regions as a top-level construct, with region-specific 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 lists.jboss.org  Mon Aug  6 12:50:49 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 6 Aug 2007 12:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1062) Include
 DefaultSpecificationEntries and DefaultImplementationEntries in jar
 manifests
Message-ID: <28007138.1186419049320.JavaMail.jira@cloud.prod.atl2.jboss.com>

Include DefaultSpecificationEntries and DefaultImplementationEntries in jar manifests
-------------------------------------------------------------------------------------

                 Key: JBRULES-1062
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1062
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
            Priority: Trivial
             Fix For: 4.0.1


See "Is there a method to return running jBoss Rules	version" on user mailing 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 lists.jboss.org  Mon Aug  6 12:54:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Mon, 6 Aug 2007 12:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20166121.1186419289578.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-449?page=comments#action_12371229 ] 
            
Anders Andersen commented on JBAOP-449:
---------------------------------------

As I write in the issue I have tried to seperate the two by space, comma, colon and semi colon.
In all cases it seems as the compiler tries to open the complete-string-argument as a single file, what naturally fails.

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Mon Aug  6 12:54:49 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 6 Aug 2007 12:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1062) Include
 DefaultSpecificationEntries and DefaultImplementationEntries in jar
 manifests
In-Reply-To: <28007138.1186419049320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21028031.1186419289710.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet resolved JBRULES-1062.
---------------------------------------

    Resolution: Done

fixed

> Include DefaultSpecificationEntries and DefaultImplementationEntries in jar manifests
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1062
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1062
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> See "Is there a method to return running jBoss Rules	version" on user mailing 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 lists.jboss.org  Mon Aug  6 13:04:51 2007
From: jira-events at lists.jboss.org (tmullett (JIRA))
Date: Mon, 6 Aug 2007 13:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1033) string_max
 parameterization doesn't work
In-Reply-To: <19022120.1186174849551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27184107.1186419891309.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1033?page=comments#action_12371235 ] 
            
tmullett commented on JBPM-1033:
--------------------------------

I tried it with the hibernate 3.2.3ga that comes with the jbpm-jpdl 3.2.1 download, with the same results. I tried rolling back a little further (3.0.5) but that version complained about some of the named queries.



> string_max parameterization doesn't work 
> -----------------------------------------
>
>                 Key: JBPM-1033
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1033
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: WIndows XP, Hibernate 3.2.4.sp1, Java 1.4.2
>            Reporter: tmullett
>         Assigned To: Tom Baeyens
>
> Fields in the hibernate mapping files declared as type "string_max" should be truncated to the parameterized length. The mapping files do this parameterization with a "length" attribute on the property element. It looks like this (from ActionLog.hbm.xml):
> <property name="exception"
>               type="string_max"
>               column="EXCEPTION_"
>               length="4000" />
> 4000 also happens to be what StringMax will use if it can't find or parse its parameterization. We needed to shorten some fields to fit jBpm into MS SQL Server. When we shortened the length, we noticed that the parameter was being ignored, causing jdbc to blow chunks.  org.jbpm.db.hibernate.StringMax.setParameterValues() always gets a null passed in for it's parameters with this setup. To get it to work , we changed it to 
>     <property name="exception" column="EXCEPTION_">
> 		<type name="string_max">
> 			<param name="length">1000</param>
> 		</type>
>     </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 lists.jboss.org  Mon Aug  6 13:15:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 6 Aug 2007 13:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10048215.1186420549654.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1060:
----------------------------------

    Fix Version/s: 4.0.1

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Mon Aug  6 15:33:59 2007
From: jira-events at lists.jboss.org (Jacques Belissent (JIRA))
Date: Mon, 6 Aug 2007 15:33:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-868)
 java.lang.IllegalArgumentException: Unable to find operation XYZ for
 dependent beans in seperate jars
In-Reply-To: <5235901.1170897390091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26902527.1186428839591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-868?page=comments#action_12371241 ] 
            
Jacques Belissent commented on EJBTHREE-868:
--------------------------------------------

I think I am hitting this bug.  

Is there a workaround other than upgrading

> java.lang.IllegalArgumentException: Unable to find operation XYZ for dependent beans in seperate jars
> -----------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-868
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-868
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.0 GA
>
>
> java.lang.IllegalArgumentException: Unable to find operation sayHello()
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
> 	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
> 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
> 	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:263)
> 	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:999)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:454)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261)
> Caused by: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:231)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy89.sayHello(Unknown Source)
> 	at org.jboss.ejb3.test.dependency.ABean.getHelloB(ABean.java:18)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 15:53:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 15:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14291104.1186430029408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers reopened GPD-78:
--------------------------

             
reopening because of http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115265&start=0&postdays=postDays&postorder=postOrder&highlight=highlight

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Mon Aug  6 15:55:58 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 15:55:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23791579.1186430158663.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers updated GPD-78:
-------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115265&start=0&postdays=postDays&postorder=postOrder&highlight=highlight
        Affects Version/s: jBPM JPDL Designer 3.1.0.beta2
                               (was: jBPM JPDL Designer 3.1.0.alpha4)

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Mon Aug  6 15:59:49 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Mon, 6 Aug 2007 15:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1051) Guided Editor
 does not remmeber the folder location for new editors
In-Reply-To: <9802279.1185911089373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30146865.1186430389313.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ahti Kitsik resolved JBRULES-1051.
----------------------------------

    Resolution: Done
      Assignee: Mark Proctor  (was: Ahti Kitsik)

new file wizard/dialog fixed.

> Guided Editor does not remmeber the folder location for new editors
> -------------------------------------------------------------------
>
>                 Key: JBRULES-1051
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1051
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> The guided editor should remember the target folder when being 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 lists.jboss.org  Mon Aug  6 16:17:07 2007
From: jira-events at lists.jboss.org (Niall P (JIRA))
Date: Mon, 6 Aug 2007 16:17:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <6214910.1186431427591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12371246 ] 
            
Niall P commented on JBAS-2299:
-------------------------------

BeanUtils 1.8.0 Beta has been released for testing.

See http://www.apachenews.org/archives/001045.html

Would be good if you could test whether this issue has been resolved before the final 1.8.0 release

Niall

> 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.2.2.GA
>
>         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 lists.jboss.org  Mon Aug  6 16:39:57 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Aug 2007 16: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: <23729028.1186432797846.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBAS-2299:
----------------------------------

    Attachment: Sampleapp.zip

> 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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Mon Aug  6 16:43:49 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Mon, 6 Aug 2007 16:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
Message-ID: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>

ConfigInfoElementDomAdapter doesnt define node types
----------------------------------------------------

                 Key: GPD-129
                 URL: http://jira.jboss.com/jira/browse/GPD-129
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:

<?xml version="1.0"?>

<process-definition name="Movie" version="11">
<start-state name="Start">
<transition to="Get MPEG Properties" />
	</start-state>
<node name="Get MPEG Properties">
			<action class="SomeActionHandler"><send>010901</send>
<keys>
		<entry>
                                            <key>VarName</key>
                                            <value>1122</value>
                                </entry>
	</keys>
	<receive>
		<element>030101</element>
		<element>030102</element>	
	</receive>
</action>
				<transition to="End"/>	</node>
<end-state name="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 lists.jboss.org  Mon Aug  6 16:47:49 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Mon, 6 Aug 2007 16:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-130) Class Cast exception in
 ConfigInfoElement.getConfigInfoElements()
Message-ID: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>

Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
------------------------------------------------------------------

                 Key: GPD-130
                 URL: http://jira.jboss.com/jira/browse/GPD-130
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 16:50:04 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Mon, 6 Aug 2007 16:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-131)
 XmlAdapter.getTextContent() appends null
Message-ID: <7479123.1186433404059.JavaMail.jira@cloud.prod.atl2.jboss.com>

XmlAdapter.getTextContent() appends null
----------------------------------------

                 Key: GPD-131
                 URL: http://jira.jboss.com/jira/browse/GPD-131
             Project: JBoss jBPM GPD
          Issue Type: Bug
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


the getTextContent() method in XmlAdapter class. There should be a null check while getting the node value (this issue also comes up when you have nested configInfoElements). So the following method in XmlAdapter.java : 


protected String getTextContent() {
		StringBuffer buffer = new StringBuffer();
		NodeList list = getNode().getChildNodes();
		for (int i = 0; i < list.getLength(); i++) {
			buffer.append(list.item(i).getNodeValue());
		}
		return buffer.toString().trim();
	}
	 

should be changed to: 


protected String getTextContent() {
		StringBuffer buffer = new StringBuffer();
		NodeList list = getNode().getChildNodes();
		for (int i = 0; i < list.getLength(); i++) {
			String nodeValue = list.item(i).getNodeValue();
			if (nodeValue != null)
				buffer.append(nodeValue);
		}
		return buffer.toString().trim();
	}
	 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 16:55:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 6 Aug 2007 16:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-360) Retrotranslated
 project dependencies
In-Reply-To: <24574832.1177365880415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26934210.1186433749308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-360?page=all ]

Paul Gier closed JBBUILD-360.
-----------------------------

    Resolution: Done

A projects dependencies can now be retro-translated and then either installed to a local repo or deployed to a remote repo.

> Retrotranslated project dependencies
> ------------------------------------
>
>                 Key: JBBUILD-360
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-360
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-retro-plugin
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-retro-plugin-1.0
>
>
> The jboss-retro plugin should be able to translated a project's dependency jars along with the main project artifact.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 17:14:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 6 Aug 2007 17:14:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1051) Guided Editor
 does not remmeber the folder location for new editors
In-Reply-To: <9802279.1185911089373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4493983.1186434890357.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1051:
----------------------------------

    Assignee: Ahti Kitsik  (was: Mark Proctor)

> Guided Editor does not remmeber the folder location for new editors
> -------------------------------------------------------------------
>
>                 Key: JBRULES-1051
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1051
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> The guided editor should remember the target folder when being 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 lists.jboss.org  Mon Aug  6 17:24:49 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 6 Aug 2007 17:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
Message-ID: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>

Leak in org/jboss/mx/loading/UnifiedClassLoader3
------------------------------------------------

                 Key: JBAS-4593
                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ClassLoading
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Mike Millson
         Assigned To: Scott M Stark


[description pasted from support case]

After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.amfam" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:

found a path to the target: 26093 (depth: 5)
0 0 Heap root
26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
160611 0 Instance: [Ljava/lang/Object;
161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
217357 0 Instance: Ljavax/management/Notification;
26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;

So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.

Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 18:03:49 2007
From: jira-events at lists.jboss.org (Rajesh Rajasekaran (JIRA))
Date: Mon, 6 Aug 2007 18:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1160)
 org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
Message-ID: <19125763.1186437829351.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
-------------------------------------------------------------------------

                 Key: JBCACHE-1160
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1160
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Rajesh Rajasekaran
         Assigned To: Jason T. Greene


http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/20070806045019/results/org/jboss/cache/pojo/rollback/InMemoryTxUndoTest(tcp).html

The test attaches a second Person object to an existing node (Person object) within the scope of a transaction and rolls back.
The following exception occurs when trying to retrieve the first object.

testSimpleTxWithRollback3	
Error	org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4

org.jboss.cache.pojo.PojoCacheAlreadyDetachedException: org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4 at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.verifyAttached(CacheFieldInterceptor.java:177) at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.invoke(CacheFieldInterceptor.java:153) at org.jboss.cache.pojo.test.Person$age_Get.invokeNext(Person$age_Get.java) at org.jboss.cache.pojo.test.Person.age_r_$aop(Person.java) at org.jboss.cache.pojo.test.Person.getAge(Person.java:76) at org.jboss.cache.pojo.rollback.InMemoryTxUndoTest.testSimpleTxWithRollback3(InMemoryTxUndoTest.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 18:08:49 2007
From: jira-events at lists.jboss.org (Rajesh Rajasekaran (JIRA))
Date: Mon, 6 Aug 2007 18:08:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1161) PojoCache
 loadtime example failure
Message-ID: <17873568.1186438129330.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache loadtime example failure
----------------------------------

                 Key: JBCACHE-1161
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1161
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Rajesh Rajasekaran
         Assigned To: Jason T. Greene


The following exceptions occurs when running the example under JBossCache-pojo-2.0.0.GA\examples\PojoCache\loadtime
"build.bat compile" &  "build.bat run.loadtime.example"

     [java] Exception in thread "main" java.lang.IllegalArgumentException: PojoCache.putObject(): Object type is neither  aspectized nor Serializable nor an array of prim
itives. Object class name is examples.Student
     [java]     at org.jboss.cache.pojo.util.AopUtil.checkObjectType(AopUtil.java:125)
     [java]     at org.jboss.cache.pojo.interceptors.CheckNonSerializableInterceptor.invoke(CheckNonSerializableInterceptor.java:36)
     [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
     [java]     at org.jboss.cache.pojo.interceptors.CheckIdInterceptor.invoke(CheckIdInterceptor.java:33)
     [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
     [java]     at org.jboss.cache.pojo.interceptors.PojoBeginInterceptor.invoke(PojoBeginInterceptor.java:36)
     [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
     [java]     at test.examples.StudentMaintTest.testPropagation(StudentMaintTest.java:99)
     [java]     at test.examples.StudentMaintTest.main(StudentMaintTest.java:145)
     [java] Java Result: 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 lists.jboss.org  Mon Aug  6 20:22:49 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 6 Aug 2007 20:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1063) Failing location
 determination tests
Message-ID: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>

Failing location determination tests
------------------------------------

                 Key: JBRULES-1063
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 4.0.1
            Reporter: Philippe Ombredanne
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  

Their name is prefixed with FAILING

I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 21:29:51 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Aug 2007 21:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <5407486.1186450191138.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12371261 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

started a discussion on Apache:

https://issues.apache.org/jira/browse/BEANUTILS-291

> 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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Tue Aug  7 00:01:21 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Aug 2007 00:01:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4594) Fix JBossMessaging
	testcases
Message-ID: <29262583.1186459281761.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix JBossMessaging testcases
----------------------------

                 Key: JBAS-4594
                 URL: http://jira.jboss.com/jira/browse/JBAS-4594
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For:  JBossAS-5.0.0.Beta3


I created a task just to associate my commits while fixing the JBossMessaging/generic JMS 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 lists.jboss.org  Tue Aug  7 00:07:05 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Aug 2007 00:07:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4585) System Properties
 not being parsed on MBeans
In-Reply-To: <23803324.1185569447124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4642889.1186459625563.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBAS-4585:
----------------------------------

    Summary: System Properties not being parsed on MBeans  (was: Properties not being correctly parsed on JCA)

> System Properties not being parsed on MBeans
> --------------------------------------------
>
>                 Key: JBAS-4585
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4585
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  JBossAS-5.0.0.Beta3
>            Reporter: Clebert Suconic
>         Assigned To: Scott M Stark
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 02:15:49 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 02:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-116) Validation of
 paths on case insensative file systems
In-Reply-To: <22397393.1165080415856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21001710.1186467349414.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Scott M Stark updated JBMICROCONT-116:
--------------------------------------

    Fix Version/s: JBossMC-2.0.0.CR1
                       (was: JBossMC-2.0.0.Beta4)

> Validation of paths on case insensative file systems
> ----------------------------------------------------
>
>                 Key: JBMICROCONT-116
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-116
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: VFS
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>            Priority: Critical
>             Fix For: JBossMC-2.0.0.CR1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Remy brought up the issue of being able to validate whether a given url mapping is valid when case insensative file systems are in use. See the forum reference for the details.
> We should be able to configure the VFS file context to allow for case sensative finds when the underlying file system is not case sensative.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 02:47:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 02:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4595) Inconclusive
 exception thrown by HttpNamingContextFactory
Message-ID: <28863406.1186469269372.JavaMail.jira@cloud.prod.atl2.jboss.com>

Inconclusive exception thrown by HttpNamingContextFactory
---------------------------------------------------------

                 Key: JBAS-4595
                 URL: http://jira.jboss.com/jira/browse/JBAS-4595
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.1.GA
         Environment: Hudson only
Sun VM 1.5.0_12-b04
Ubuntu 6.06
            Reporter: Carlo de Wolf
            Priority: Minor
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


javax.naming.NamingException: Failed to retrieve Naming interface [Root exception is java.net.ConnectException: Connection refused]
	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:84)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
	at javax.naming.InitialContext.init(InitialContext.java:223)
	at javax.naming.InitialContext.<init>(InitialContext.java:197)
	at org.jboss.ejb3.test.invoker.unit.InvokerTestCase.testHttp(InvokerTestCase.java:55)
	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.net.ConnectException: Connection refused
	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
	at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1223)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1217)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906)
	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:133)
	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:80)
	... 26 more
Caused by: java.net.ConnectException: Connection refused
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
	at java.net.Socket.connect(Socket.java:519)
	at java.net.Socket.connect(Socket.java:469)
	at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
	at sun.net.www.http.HttpClient.New(HttpClient.java:304)
	at sun.net.www.http.HttpClient.New(HttpClient.java:316)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:813)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:765)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:690)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934)
	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1903)
	at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:573)
	at java.net.URLConnection.getContentLength(URLConnection.java:468)
	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:128)
	... 27 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 lists.jboss.org  Tue Aug  7 02:47:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 02:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4595) Inconclusive
 exception thrown by HttpNamingContextFactory
In-Reply-To: <28863406.1186469269372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22488859.1186469269517.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf reassigned JBAS-4595:
-----------------------------------

    Assignee: Carlo de Wolf

> Inconclusive exception thrown by HttpNamingContextFactory
> ---------------------------------------------------------
>
>                 Key: JBAS-4595
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4595
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>         Environment: Hudson only
> Sun VM 1.5.0_12-b04
> Ubuntu 6.06
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Minor
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> javax.naming.NamingException: Failed to retrieve Naming interface [Root exception is java.net.ConnectException: Connection refused]
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:84)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
> 	at javax.naming.InitialContext.init(InitialContext.java:223)
> 	at javax.naming.InitialContext.<init>(InitialContext.java:197)
> 	at org.jboss.ejb3.test.invoker.unit.InvokerTestCase.testHttp(InvokerTestCase.java:55)
> 	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.net.ConnectException: Connection refused
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> 	at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1223)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1217)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:133)
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:80)
> 	... 26 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> 	at java.net.Socket.connect(Socket.java:519)
> 	at java.net.Socket.connect(Socket.java:469)
> 	at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:304)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:316)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:813)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:765)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:690)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934)
> 	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1903)
> 	at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:573)
> 	at java.net.URLConnection.getContentLength(URLConnection.java:468)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:128)
> 	... 27 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 lists.jboss.org  Tue Aug  7 03:00:49 2007
From: jira-events at lists.jboss.org (Dr. Gernot Starke (JIRA))
Date: Tue, 7 Aug 2007 03:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1064) "->" notation for
 predicates missing in documentation
Message-ID: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>

"->" notation for predicates missing in documentation
-----------------------------------------------------

                 Key: JBRULES-1064
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.GA
            Reporter: Dr. Gernot Starke
         Assigned To: Mark Proctor
            Priority: Minor


the notation "->" for adressing complex terms is missing from 4.0.0 documentation.

It has been "return value operator" in 3.0.6:

<quoted from 3.0.6>
Example 3.13. Return Value operator

Person( girlAge : age, sex = "F" )
Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
</quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 03:31:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 03:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4595) Inconclusive
 exception thrown by HttpNamingContextFactory
In-Reply-To: <28863406.1186469269372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31016707.1186471909405.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved JBAS-4595.
---------------------------------

    Resolution: Done

> Inconclusive exception thrown by HttpNamingContextFactory
> ---------------------------------------------------------
>
>                 Key: JBAS-4595
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4595
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>         Environment: Hudson only
> Sun VM 1.5.0_12-b04
> Ubuntu 6.06
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Minor
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> javax.naming.NamingException: Failed to retrieve Naming interface [Root exception is java.net.ConnectException: Connection refused]
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:84)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
> 	at javax.naming.InitialContext.init(InitialContext.java:223)
> 	at javax.naming.InitialContext.<init>(InitialContext.java:197)
> 	at org.jboss.ejb3.test.invoker.unit.InvokerTestCase.testHttp(InvokerTestCase.java:55)
> 	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.net.ConnectException: Connection refused
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> 	at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1223)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1217)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:133)
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:80)
> 	... 26 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> 	at java.net.Socket.connect(Socket.java:519)
> 	at java.net.Socket.connect(Socket.java:469)
> 	at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:304)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:316)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:813)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:765)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:690)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934)
> 	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1903)
> 	at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:573)
> 	at java.net.URLConnection.getContentLength(URLConnection.java:468)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:128)
> 	... 27 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 lists.jboss.org  Tue Aug  7 03:33:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 03:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1026) Refactor
 extended persistence context
Message-ID: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor extended persistence context
-------------------------------------

                 Key: EJBTHREE-1026
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1026
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf
             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Tue Aug  7 05:03:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-132) random duedate
 attributes appear on task elements
Message-ID: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>

random duedate attributes appear on task elements
-------------------------------------------------

                 Key: GPD-132
                 URL: http://jira.jboss.com/jira/browse/GPD-132
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: osx, macbook pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Minor


while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:08:26 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:08:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
Message-ID: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>

with two transitions from a node, both need to be labelled, or jbpm-console exceptions
--------------------------------------------------------------------------------------

                 Key: GPD-133
                 URL: http://jira.jboss.com/jira/browse/GPD-133
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: osx, macbook pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers


when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:10:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-134) form file names
 generated from the task dialogue are unstable
Message-ID: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>

form file names generated from the task dialogue are unstable
-------------------------------------------------------------

                 Key: GPD-134
                 URL: http://jira.jboss.com/jira/browse/GPD-134
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: osx macbook pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Minor


the form names generated from the task dialogue are sensitive to content...

'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console

the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:12:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:12:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7755449.1186477969363.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Component/s: jpdl

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19436343.1186478209520.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-132?page=comments#action_12371283 ] 
            
Koen Aers commented on GPD-132:
-------------------------------

Ross,

AFAIR duedate is a mandatory attribute on some elements. What elements are you talking about?

Regards,
Koen

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:19:14 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:19:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3146099.1186478354838.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371285 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

Can you provide an example of this situation? A minimal processdefinition and the accompanying task form that produces the problem e.g.

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:19:14 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:19:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17773892.1186478354965.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371286 ] 
            
Koen Aers commented on GPD-134:
-------------------------------

Do you have any indication about database specificity? What DB are you using?

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:30:32 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:30:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-135) bendpoints are not
 properly drawn when reading a processdefinition from disk
Message-ID: <18689252.1186479032370.JavaMail.jira@cloud.prod.atl2.jboss.com>

bendpoints are not properly drawn when reading a processdefinition from disk
----------------------------------------------------------------------------

                 Key: GPD-135
                 URL: http://jira.jboss.com/jira/browse/GPD-135
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Koen Aers
         Assigned To: Koen Aers
             Fix For: jBPM JPDL Designer 3.1.0.CR




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:30:32 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:30:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18367646.1186479032539.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-132?page=comments#action_12371290 ] 
            
Ross McDonald commented on GPD-132:
-----------------------------------

Hi,

apologies, the duedate attributes appear on task elements, generated somehow from the Tasks > Details dialogue, although I am not attempting to specify a duedate, as their is no duedate for the task, this is occurring infrequently,

cheers

Ross

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:32:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5811580.1186479169361.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371291 ] 
            
Ross McDonald commented on GPD-134:
-----------------------------------

Hi,

sure sorry, was reporting all of these issues in a hurry before a demo to the boss :-)

I am using Mysql 5.0.37, can provide hibernate connection into and config if required,

cheers

Ross

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:34:49 2007
From: jira-events at lists.jboss.org (Felipe (JIRA))
Date: Tue, 7 Aug 2007 05:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-272) allow xpath
 expression/query to create more than one occurrence of an element
In-Reply-To: <21460509.1185436907082.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9300617.1186479289300.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-272?page=comments#action_12371292 ] 
            
Felipe commented on BPEL-272:
-----------------------------

WORKAROUND UNTIL THIS IS FIXED:

Following the oracle approach (cf. supra.), a web service can be used to provide an operation that returns an array of the right size. Operations to add items can be done too. Z.B. creating a lista of size four:

ESQUEMA:
   <complexType name="ListaString">
     <sequence>
       <element name="item" type="xsd:string" minOccurs="1" maxOccurs="unbounded"></element>
     </sequence>
   </complexType>
WSDL:
   <wsdl:message name="obtenerListaStringRequest">
   	<wsdl:part name="obtenerListaStringRequest" type="xsd:int"></wsdl:part>
   </wsdl:message>
   <wsdl:message name="obtenerListaStringResponse">
   	<wsdl:part name="obtenerListaStringReturn"
   		type="tns1:ListaString">
   	</wsdl:part>
   </wsdl:message>
      <wsdl:operation name="obtenerListaString">
      	<wsdl:documentation>Este m?todo fue a?adido para corregir las deficiencias del bpel en la creaci?n de secuencias. Cf. http://jira.jboss.com/jira/browse/BPEL-272</wsdl:documentation>
      	<wsdl:input message="impl:obtenerListaStringRequest" name="listaStringPedir"></wsdl:input>
      	<wsdl:output message="impl:obtenerListaStringResponse" name="listaStringDevolver"></wsdl:output>
      </wsdl:operation>
BPEL:
<variable name="listacadenas" messageType="BAncha:obtenerListaStringResponse" />
    <variable name="entero" messageType="BAncha:obtenerListaStringRequest"/>
<assign>
  	<copy>
  		<from expression="4"/>
  		<to variable="entero" part="obtenerListaStringRequest"/>
  	</copy>
  </assign>
    <invoke partnerLink="BaPartnerLink" portType="BA:Bara"
              operation="obtenerListaString" inputVariable="entero"
              outputVariable="listacadenas"/>

  Haleeee

> allow xpath expression/query to create more than one occurrence of an element
> -----------------------------------------------------------------------------
>
>                 Key: BPEL-272
>                 URL: http://jira.jboss.com/jira/browse/BPEL-272
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The current XPath sublanguage implementation automatically creates nodes missing from location paths during assignment. This facility has a number of conceptual limitations. One of them is the inability to append a child element to an existing element if the latter already has a child element with the same name. There is no XPath syntax to express that a new element is required!
> It is tempting to think of a numeric XPath predicate as an array index, leading to the next snippet:
> <copy>
>  <from><literal>haha</literal></from>
>  <to variable='laughter' xmlns:ex='http://jbpm.org/bpel/examples'>
>   <query>ex:laugh[last() + 1]</query>
>  </to>
> </copy>
> However, such an interpretation of a predicate is wrong. Consider the following extract from XPath 1.0 specification on predicates:
> "A PredicateExpr is evaluated by evaluating the Expr and converting the result to a boolean. If the result is a number, the result will be converted to true if the number is equal to the context position and will be converted to false otherwise."
> The description of the last() function reads:
> "The last function returns a number equal to the context size from the expression evaluation context."
> Noticed the problem? The context position is never greater than the context size. Therefore the predicate [last() + 1] does not represent the position "one past the context size" but the boolean value false. Unfortunately, no other predicate seems appropriate. 
> PROPOSAL Introduce a minor deviation from the XPath 1.0 specification. Interpret the result of a numeric predicate that equals the context size plus one as a  request to create a new occurrence of the 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 lists.jboss.org  Tue Aug  7 05:59:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28640634.1186480789466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371294 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

Hi, sure, attached is the original process definition, the exception, and then the fixed definition, btw, I am running this whole thing on tomcat 5.0.28, and once this exception occurrs, the tasks view seems to be broken for good, even when I end the process, I can provide more info if needed,

cheers

Ross



> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:59:49 2007
From: jira-events at lists.jboss.org (Jiri Pechanec (JIRA))
Date: Tue, 7 Aug 2007 05:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1034) DB test suites are
	not operationg
Message-ID: <2673921.1186480789623.JavaMail.jira@cloud.prod.atl2.jboss.com>

DB test suites are not operationg
---------------------------------

                 Key: JBPM-1034
                 URL: http://jira.jboss.com/jira/browse/JBPM-1034
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
         Environment: Hudson QE
            Reporter: Jiri Pechanec
         Assigned To: Tom Baeyens


The database related test cases are failing due to Hibernate misconfiguration. Either the wrong property file is read or the value inside are incorrect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:59:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23505372.1186480789783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Attachment: broken_process.xml

the broken example process

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:59:50 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:59:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30653993.1186480790016.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Attachment: broken_process_exception.txt

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:01:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 06:01:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25511451.1186480909395.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Attachment: fixed_process.xml

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:01:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 06:01:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14828339.1186480909579.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28  (was: osx, macbook pro, eclipse 3.3.0)

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:43:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
In-Reply-To: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32355651.1186483429540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-129?page=all ]

Koen Aers updated GPD-129:
--------------------------

      Component/s: jpdl
    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> ConfigInfoElementDomAdapter doesnt define node types
> ----------------------------------------------------
>
>                 Key: GPD-129
>                 URL: http://jira.jboss.com/jira/browse/GPD-129
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:
> <?xml version="1.0"?>
> <process-definition name="Movie" version="11">
> <start-state name="Start">
> <transition to="Get MPEG Properties" />
> 	</start-state>
> <node name="Get MPEG Properties">
> 			<action class="SomeActionHandler"><send>010901</send>
> <keys>
> 		<entry>
>                                             <key>VarName</key>
>                                             <value>1122</value>
>                                 </entry>
> 	</keys>
> 	<receive>
> 		<element>030101</element>
> 		<element>030102</element>	
> 	</receive>
> </action>
> 				<transition to="End"/>	</node>
> <end-state name="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 lists.jboss.org  Tue Aug  7 06:43:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-130) Class Cast exception in
 ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4968845.1186483429661.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-130?page=all ]

Koen Aers updated GPD-130:
--------------------------

      Component/s: jpdl
    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:45:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-131)
 XmlAdapter.getTextContent() appends null
In-Reply-To: <7479123.1186433404059.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7423678.1186483549455.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-131?page=all ]

Koen Aers updated GPD-131:
--------------------------

          Component/s: jpdl
        Fix Version/s: jBPM JPDL Designer 3.1.0.CR
    Affects Version/s: jBPM JPDL Designer 3.1.0.beta2

> XmlAdapter.getTextContent() appends null
> ----------------------------------------
>
>                 Key: GPD-131
>                 URL: http://jira.jboss.com/jira/browse/GPD-131
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> the getTextContent() method in XmlAdapter class. There should be a null check while getting the node value (this issue also comes up when you have nested configInfoElements). So the following method in XmlAdapter.java : 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			buffer.append(list.item(i).getNodeValue());
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 
> should be changed to: 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			String nodeValue = list.item(i).getNodeValue();
> 			if (nodeValue != null)
> 				buffer.append(nodeValue);
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:45:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33400397.1186483549615.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-132?page=all ]

Koen Aers updated GPD-132:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:47:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27195101.1186483669289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Koen Aers updated GPD-133:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:49:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17233717.1186483789296.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371299 ] 
            
Koen Aers commented on GPD-134:
-------------------------------

Could you reproduce this on HSQLDB as well? Anyway, this seems to me like a plain jBPM bug which has probably nothing to do with the GPD. Maybe we should move this to the jBPM project.

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:51:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:51:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-39) Adapt property sheet
 according to context in xml tab
In-Reply-To: <31483791.1168964513032.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1070617.1186483909718.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-39?page=all ]

Koen Aers updated GPD-39:
-------------------------

    Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)

> Adapt property sheet according to context in xml tab
> ----------------------------------------------------
>
>                 Key: GPD-39
>                 URL: http://jira.jboss.com/jira/browse/GPD-39
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> Currently the property sheet does not reflect the context when editing the process definition in the xml source tab.
> Solution : define a selection listener that activates the model object corresponding to the cursor location in the xml source tab.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:51:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:51:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-54) Label and name support
 for graph elements
In-Reply-To: <17703731.1170780140362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11885376.1186483910163.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-54?page=all ]

Koen Aers updated GPD-54:
-------------------------

    Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)

> Label and name support for graph elements
> -----------------------------------------
>
>                 Key: GPD-54
>                 URL: http://jira.jboss.com/jira/browse/GPD-54
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:51:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:51:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-31) Make sure all tasks in
 a process definition have a unique name
In-Reply-To: <27583187.1168958633498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31493502.1186483910246.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-31?page=all ]

Koen Aers updated GPD-31:
-------------------------

    Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)

> Make sure all tasks in a process definition have a unique name
> --------------------------------------------------------------
>
>                 Key: GPD-31
>                 URL: http://jira.jboss.com/jira/browse/GPD-31
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> When retrieving all tasks from a process definition like so:
>         processDefinition.getTaskMgmtDefinition().getTasks() 
> it returns a MAP of tasks, keyed by task name. This is a problem if two tasks anywhere in the same process definition have the same name.
> By default, the GPD creates all tasks as "task1" when it is the first task on a task node. If none of these were renamed, you would only get a single task when trying to get all of them for the 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 lists.jboss.org  Tue Aug  7 06:53:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-20) refactor naming strategy
In-Reply-To: <32621900.1168954252939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18049592.1186484029301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-20?page=all ]

Koen Aers updated GPD-20:
-------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0 alpha1)

> refactor naming strategy
> ------------------------
>
>                 Key: GPD-20
>                 URL: http://jira.jboss.com/jira/browse/GPD-20
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> 1) generate default node names when nodes are created: {node1, node2, ...}. use this naming strategy for each node type.
> 2) do not generate a node name for the start-state. users should be able to give the start-state a name, though.
> 3) use the following naming strategy for end states: {end, end2, end3, end4, ...}
> 4) do not generate names for transitions. the problem reporting should generate warnings if a node-type requires named nodes. the correlation between the graphical information and the processdefinition.xml will be done based on the position (index), rather then on the name.
> 5) disallow slashes in names in a process definition (nodes, transitions, process definition, actions, ...) Because slashes will be used as a separator in hierarchical names. We should also investigate if it would be useful to specify a strict set of chars that can be used like e.g. 0-9,a-z,A-Z,space,dot

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:58:08 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 06:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23863091.1186484288301.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371301 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Is it by intention, that the default priority is MAXINT, if you do not set a value for "mapperClassPriority"?
Because of that, it is not possible to activate a mapping on an existing xml types, since the existing semantic element is always first in the SortedSet.
So I have to set mapperClassPriority for this existing xml mapping.
Or am I missing something?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 07:09:49 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 07:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-136) Widget is disposed in
 Task Controller Variables Table
Message-ID: <24052817.1186484989796.JavaMail.jira@cloud.prod.atl2.jboss.com>

Widget is disposed in Task Controller Variables Table
-----------------------------------------------------

                 Key: GPD-136
                 URL: http://jira.jboss.com/jira/browse/GPD-136
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: Eclipse 3.2.2 on Windows 2000
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


Select a Task Node. Go to Properties View.
Select Tasks:<task>:Controller (default).
Add two variables, remove the second.
Error Log view contains the following SWT Exception:
org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.swt.SWT.error(SWT.java:3374)
	at org.eclipse.swt.SWT.error(SWT.java:3297)
	at org.eclipse.swt.SWT.error(SWT.java:3268)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:435)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:330)
	at org.eclipse.swt.widgets.Control.setVisible(Control.java:2642)
	at org.jbpm.gd.jpdl.util.VariableTableItemWrapper.applyName(VariableTableItemWrapper.java:164)
	at org.jbpm.gd.jpdl.util.VariableTableItemWrapper.cancelEditing(VariableTableItemWrapper.java:150)
	at org.jbpm.gd.jpdl.util.VariableTableCellClickedResolver.mouseDown(VariableTableCellClickedResolver.java:25)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:133)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1930)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:422)
	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)
After that, table input is not working anymore ("Mapped Name" column not editable anymore, 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 lists.jboss.org  Tue Aug  7 08:00:52 2007
From: jira-events at lists.jboss.org (Takayuki Kaneko (JIRA))
Date: Tue, 7 Aug 2007 08:00:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4590) Add new parameter of
 jnp for connecting each time.
In-Reply-To: <28892709.1186042971102.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21463105.1186488052934.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Takayuki Kaneko updated JBAS-4590:
----------------------------------

        Fix Version/s: JBossAS-4.2.2.GA
                       JBossAS-4.0.5.SP1 
    Affects Version/s: JBossAS-4.2.1.GA
                       JBossAS-4.0.5.GA

> Add new parameter of jnp for connecting each time.
> --------------------------------------------------
>
>                 Key: JBAS-4590
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4590
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA
>            Reporter: Takayuki Kaneko
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.SP1 , JBossAS-4.2.2.GA
>
>         Attachments: patch.txt
>
>
> I want to add a new parameter on org.jnp.interfaces.NamingContext for connecting 1099 port each time.
> Our system needs to connect JNDI each time because there is a load balancer between EJB clients and JBoss servers.
> Of course I know the caching server stubs is needed to improve the performance. Our issue might be minority.
> So I made a patch that wouldn't change the default behavior about caching.
> Could you consider the possibilities of applying this patch? We want to use JBoss Application Server on our system.
> 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 lists.jboss.org  Tue Aug  7 08:00:53 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 08:00:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32840182.1186488053264.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371313 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

The value MAX_VALUE was originally chosen because this would be the lowest priority (huh?).

The (second) mistake was that I assumed wrongly the wrong order within the sorted set. 

I think it would indeed be best to do as you suggest and assume MIN_VALUE for the default priority and let contributors specify higher priorities if they want their mapper to take over. If I am not mistaken, the ordering should be from high to low now with the latest commit. Can anyone verify?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 08:10:49 2007
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 7 Aug 2007 08:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4596) Provide
 web-jsptaglibrary_2_1.xsd in $JBOSS_HOME/docs/schema
Message-ID: <17317840.1186488649656.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide web-jsptaglibrary_2_1.xsd in $JBOSS_HOME/docs/schema
------------------------------------------------------------

                 Key: JBAS-4596
                 URL: http://jira.jboss.com/jira/browse/JBAS-4596
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.2.GA
            Reporter: Juergen Zimmermann


When implementing custom TLD files then it makes sense to use the ANT task <schemavalidate> to validate the .tld file. Therefore,  web-jsptaglibrary_2_1.xsd should be provided in $JBOSS_HOME/docs/schema.

BTW, web-jsptaglibrary_2_0.xsd is already in $JBOSS_HOME/docs/schema

web-jsptaglibrary_2_1.xsd is contained in server/default/lib/jsp-api.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 lists.jboss.org  Tue Aug  7 08:20:49 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 08:20:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7061661.1186489249365.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371314 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

I would choose 0 as default, because with extreme values you have easily an overflow in the comparator calculation.
Your change had no impact in my use case. I have chose priority 1 for my mapping.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 08:26:49 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 08:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12169841.1186489609343.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371315 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Now it's clear.
Before your change it was: MAX -1 > 0
After your change it was MIN -1 > 0 because of overflow
   

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 08:57:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 08:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <577290.1186491469308.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371317 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Okay, this makes a lot of sense... 0 it will be ;-)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:05:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16521886.1186491949289.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371318 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

It is changed to 0 now. Please check again (but allow half an hour time for the public cvs to synchronize)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:14:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-81) Add support for
 reconnecting transitions
In-Reply-To: <898355.1178879092359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8099900.1186492489599.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-81?page=all ]

Koen Aers updated GPD-81:
-------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.alpha4)

> Add support for reconnecting transitions
> ----------------------------------------
>
>                 Key: GPD-81
>                 URL: http://jira.jboss.com/jira/browse/GPD-81
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: Clean eclipse 3.2.2 and gpd 3.1alpha4
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>
> Not being able to reconnect transitions graphically from e.g. node a to node b is still a big omission for the gpd to be used by 'grey suites' as well as 'jeans and t-shirts', at least within our company. I thought there was a long standing issue for this, but I cannot find it. 
> If someone could point me to a place to start looking into this, I'd be happy to try to implement this (but it will be the only gpd thing I 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 lists.jboss.org  Tue Aug  7 09:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-100) review the delegation
 configuration form
In-Reply-To: <9679061.1182417596922.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <699372.1186492609421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-100?page=all ]

Koen Aers updated GPD-100:
--------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.alpha4)

> review the delegation configuration form
> ----------------------------------------
>
>                 Key: GPD-100
>                 URL: http://jira.jboss.com/jira/browse/GPD-100
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> - have a look at the visibility of the text and table in the configuration form
> - try to fix the resize problem

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-109) review task form
	generation dialog
In-Reply-To: <22119502.1182883917540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1086988.1186492609514.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-109?page=all ]

Koen Aers updated GPD-109:
--------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.beta1)

> review task form generation dialog
> ----------------------------------
>
>                 Key: GPD-109
>                 URL: http://jira.jboss.com/jira/browse/GPD-109
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> implement focuslost behaviour

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:18:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
In-Reply-To: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19404069.1186492729292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-129?page=all ]

Koen Aers resolved GPD-129.
---------------------------

    Resolution: Done

I have fixed this. Have a look and inform me if it works for you. Note that I have refactored the name from ConfigInfoElement to GenericElement

> ConfigInfoElementDomAdapter doesnt define node types
> ----------------------------------------------------
>
>                 Key: GPD-129
>                 URL: http://jira.jboss.com/jira/browse/GPD-129
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:
> <?xml version="1.0"?>
> <process-definition name="Movie" version="11">
> <start-state name="Start">
> <transition to="Get MPEG Properties" />
> 	</start-state>
> <node name="Get MPEG Properties">
> 			<action class="SomeActionHandler"><send>010901</send>
> <keys>
> 		<entry>
>                                             <key>VarName</key>
>                                             <value>1122</value>
>                                 </entry>
> 	</keys>
> 	<receive>
> 		<element>030101</element>
> 		<element>030102</element>	
> 	</receive>
> </action>
> 				<transition to="End"/>	</node>
> <end-state name="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 lists.jboss.org  Tue Aug  7 09:21:08 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:21:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-131)
 XmlAdapter.getTextContent() appends null
In-Reply-To: <7479123.1186433404059.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31417195.1186492868911.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-131?page=all ]

Koen Aers closed GPD-131.
-------------------------

    Resolution: Done

> XmlAdapter.getTextContent() appends null
> ----------------------------------------
>
>                 Key: GPD-131
>                 URL: http://jira.jboss.com/jira/browse/GPD-131
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> the getTextContent() method in XmlAdapter class. There should be a null check while getting the node value (this issue also comes up when you have nested configInfoElements). So the following method in XmlAdapter.java : 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			buffer.append(list.item(i).getNodeValue());
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 
> should be changed to: 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			String nodeValue = list.item(i).getNodeValue();
> 			if (nodeValue != null)
> 				buffer.append(nodeValue);
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:21:09 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 09:21:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27064863.1186492869089.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371321 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

I made exactly the same change locally and this worked :)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:24:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6162622.1186493089492.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371322 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

I don't understand this issue.

Can you elaborate on the use case and describe more in detail what happens?

Regards,
Koen

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:24:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4765767.1186493089638.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371323 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

I mean, the array should contain only ConfigInfoElements right?

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:26:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 09:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22250297.1186493209582.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

from an email with Peter Lin:
it should be configurable in the class. I don't know if kris added the configuration the IDE or not.

the reason for it was to have a smart guided editor for business users. for developers it makes more sense to only add the entire phrase instead of only showing the next words available.  I've gotten the same comment when I built a custom rule editor for pre-trade compliance.  the developers prefered to have a template style and see the entire thing.  the business users preferred guided editor that only showed the next words available.

the only real benefit of only showing the next word vs whole phrase is when the mapping file has thousands of entries. showing all available options with thousands of entries starts to get unusable. eclipse makes it less of a problem, since you can hit a letter and jump down to that section, but I find having too many options for a non-technical business user it doesn't go over so well. for compliance, we kept it down to a dozen or so.

in the DSLTree class you'll see getConditionChildrenList. if you call it with true, it will the entire phrase. I would go with what ever the users ask for myself. I suspect many of the users are primarily developers and not business users, so it's not a benefit for developers.

public ArrayList getConditionChildrenList(String text, boolean addChildren)

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Tue Aug  7 09:28:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 09:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26999748.1186493329337.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

My preference is to have the previous default behaviour. Ideally someone can change this in the Eclipse preferences panel.

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Tue Aug  7 09:30:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 09:30:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1036) dialect errors
 if after import declarations
In-Reply-To: <1942890.1185648467658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5525673.1186493449358.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

mic does not recal requesting this by design. So can we fix this for 4.0.1?

> dialect errors if after import declarations
> -------------------------------------------
>
>                 Key: JBRULES-1036
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1036
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> In the Shopping example if I have the dialect after the imports it 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 lists.jboss.org  Tue Aug  7 09:35:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-380) Allow
	annotations on packages
In-Reply-To: <28643571.1181232251888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18011506.1186493749300.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBBUILD-380?page=comments#action_12371329 ] 
            
Paul Gier commented on JBBUILD-380:
-----------------------------------

Waiting for this feature to be added to javassist.

> Allow annotations on packages
> -----------------------------
>
>                 Key: JBBUILD-380
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-380
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.1.2.GA
>
>
> Annotations on a package can be included in package-info.java.  Retro should allow annotations on packages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:37:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-379) Add support for
 getAnnotations vs getDeclaredAnnotations
In-Reply-To: <30513094.1181230094258.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31594215.1186493869951.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Paul Gier updated JBBUILD-379:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Add support for getAnnotations vs getDeclaredAnnotations
> --------------------------------------------------------
>
>                 Key: JBBUILD-379
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-379
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>    Affects Versions:  JBossRetro-1.0.5.GA
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> Currently jboss retro does not differentiate between the getAnnotations() and getDeclaredAnnotations(), this functionality should be added in a future 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 lists.jboss.org  Tue Aug  7 09:37:50 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-380) Allow annotations
	on packages
In-Reply-To: <28643571.1181232251888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31034131.1186493870195.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-380?page=all ]

Paul Gier updated JBBUILD-380:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Allow annotations on packages
> -----------------------------
>
>                 Key: JBBUILD-380
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-380
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> Annotations on a package can be included in package-info.java.  Retro should allow annotations on packages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:37:50 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-383) Complete Retro
	Mavenization
In-Reply-To: <30433964.1181834471757.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10053038.1186493870315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-383?page=all ]

Paul Gier updated JBBUILD-383:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Complete Retro Mavenization
> ---------------------------
>
>                 Key: JBBUILD-383
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-383
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> The mavenization can be completed when the next surefire plugin is released.
> Also there needs to be a way to configure the manifest file for the runtime jar.
> Look into breaking retro into three modules: weaver, retro-runtime, and maven-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 lists.jboss.org  Tue Aug  7 09:37:50 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-385) Research
 customizing package names for each release or each project.
In-Reply-To: <1040423.1181846771687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6352004.1186493870456.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-385?page=all ]

Paul Gier updated JBBUILD-385:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Research customizing package names for each release or each project.
> --------------------------------------------------------------------
>
>                 Key: JBBUILD-385
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-385
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> It could be helpful for backwards compatibility to have unique package names for each release of the retro runtime.  That way multiple versions of retro included in a product with multiple components could co-exist.
> The projects that require the retro runtime would be run against a particular version of retro and point to the appropriate fully qualified class names.  So a package name could be something like:
> org.jboss.retro.runtime_1_1_0.*

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:45:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-135) bendpoints are not
 properly drawn when reading a processdefinition from disk
In-Reply-To: <18689252.1186479032370.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <777692.1186494349531.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-135?page=all ]

Koen Aers closed GPD-135.
-------------------------

    Resolution: Done

> bendpoints are not properly drawn when reading a processdefinition from disk
> ----------------------------------------------------------------------------
>
>                 Key: GPD-135
>                 URL: http://jira.jboss.com/jira/browse/GPD-135
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:53:56 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12306168.1186494836808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-132?page=all ]

Koen Aers closed GPD-132.
-------------------------

    Resolution: Done

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:00:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 7 Aug 2007 10:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
In-Reply-To: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17930583.1186495249362.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana updated JBAS-4593:
--------------------------------

    Description: 
[description pasted from support case]

After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:

found a path to the target: 26093 (depth: 5)
0 0 Heap root
26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
160611 0 Instance: [Ljava/lang/Object;
161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
217357 0 Instance: Ljavax/management/Notification;
26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;

So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.

Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.



  was:
[description pasted from support case]

After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.amfam" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:

found a path to the target: 26093 (depth: 5)
0 0 Heap root
26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
160611 0 Instance: [Ljava/lang/Object;
161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
217357 0 Instance: Ljavax/management/Notification;
26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;

So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.

Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.




> Leak in org/jboss/mx/loading/UnifiedClassLoader3
> ------------------------------------------------
>
>                 Key: JBAS-4593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Scott M Stark
>
> [description pasted from support case]
> After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:
> found a path to the target: 26093 (depth: 5)
> 0 0 Heap root
> 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
> 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
> 160611 0 Instance: [Ljava/lang/Object;
> 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
> 217357 0 Instance: Ljavax/management/Notification;
> 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;
> So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.
> Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:02:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 10:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20290338.1186495369340.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371335 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

I think this is basically a problem in the console. 

Tom has asked a long time ago to *not* generate a name for the transition if there is only one and generate a name starting with the second transition. He even fixed this himself if I remember correctly. Now I know that this strategy is debatable and that there are a number of prominent jBPM users that prefer a default name in all cases (I think Ronald is amongst them). I even think there is a JIRA issue to reintroduce this, but I don't remember which one from the top of my head. 

The obvious workaround is to give your transitions a name as you found out.

Note that validation is pointless because the jPDL xsd does not mandate the name for the transition.

Regards,
Koen

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:04:57 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 10:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25612840.1186495497308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Koen Aers updated GPD-133:
--------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.beta1)

I will not include this different naming strategy for the upcoming release. 

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:23:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Tue, 7 Aug 2007 10:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1029) Can't use JMock
 to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30178893.1186496629363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1029?page=comments#action_12371338 ] 
            
John Doe commented on JBRULES-1029:
-----------------------------------

I recently got chance to test this and foudn very strange issue after I update from svn trunk and built/installed things with maven:

org.drools.rule.InvalidRulePackage: Unable to build expression for 'from' node 'RuleHelper.search(content,"pattern","column")' : [Rule name=Verify_1, agendaGroup=MAIN, salience=0, no-loop=false]
Rule Compilation error : [Rule name=Verify_1, agendaGroup=MAIN, salience=0, no-loop=false]
	sample/Rule_Verify_1_0.java (5:175) : ResultsInterface cannot be resolved to a type

	at org.drools.rule.Package.checkValidity(Package.java:410)
	at BasicRuleFlowTest.testGenericFlow(BasicRuleFlowTest.java:31)
	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:164)
	at junit.framework.TestCase.runBare(TestCase.java:130)
	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:120)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


the rule is exactly the same, could you please take a look at this?

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:25:49 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Tue, 7 Aug 2007 10:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-570) Complete thread
 naming for all channel threads
Message-ID: <23416128.1186496749399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Complete thread naming for all channel threads
----------------------------------------------

                 Key: JGRP-570
                 URL: http://jira.jboss.com/jira/browse/JGRP-570
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.6


We have improved thread naming in Jgroups 2.5 release. However, we still have threads in protocols above TP that are named independently of TP threads - they follow different naming pattern. We should investigate how to consistently name all threads that belong to one channel. Should we pass ThreadNamingPattern as and event through 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 lists.jboss.org  Tue Aug  7 10:25:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Tue, 7 Aug 2007 10:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1029) Can't use JMock
 to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29477702.1186496749586.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

John Doe reopened JBRULES-1029:
-------------------------------

             
I'm not sure, but probably this issue is related to some MVEL issue which should be fixed in trunk - but actually isn't?

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:30:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Tue, 7 Aug 2007 10:30:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1029) Can't use JMock
	to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24280805.1186497049347.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

John Doe updated JBRULES-1029:
------------------------------

    Attachment: drools.zip

Sample package which illustrates the issue

use 'mvn test' to see it in action

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: drools.zip
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 10:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-121) remove lookup of
 current editor to obtain commandstack
In-Reply-To: <32250260.1185378347021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27864075.1186498729265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-121?page=all ]

Koen Aers closed GPD-121.
-------------------------

    Resolution: Done

> remove lookup of current editor to obtain commandstack
> ------------------------------------------------------
>
>                 Key: GPD-121
>                 URL: http://jira.jboss.com/jira/browse/GPD-121
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 11:02:52 2007
From: jira-events at lists.jboss.org (Hany Mesha (JIRA))
Date: Tue, 7 Aug 2007 11:02:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2861) HttpSession sharing
 between WAR modules
Message-ID: <12436685.1186498972371.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Hany Mesha reassigned JBAS-2861:
--------------------------------

    Assignee: Hany Mesha  (was: Brian Stansberry)

> HttpSession sharing between WAR modules
> ---------------------------------------
>
>                 Key: JBAS-2861
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2861
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>    Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final
>            Reporter: Brian Stansberry
>         Assigned To: Hany Mesha
>             Fix For: JBossAS-4.2.2.GA
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.html?Open
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.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 lists.jboss.org  Tue Aug  7 11:02:52 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 11:02:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13092053.1186498972485.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371345 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Matthew, can you have a check if this works for you and close the issue if it does?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 11:58:49 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 11:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1622) Implement
 "admin" portlet mode
Message-ID: <22138593.1186502329360.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement "admin" portlet mode
------------------------------

                 Key: JBPORTAL-1622
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1622
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 12:23:49 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 7 Aug 2007 12:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SWAP-25) Update MyFaces JSF
 tutorial portlet to work with 2.6 and AS 4.2
Message-ID: <25738357.1186503829619.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update MyFaces JSF tutorial portlet to work with 2.6 and AS 4.2
---------------------------------------------------------------

                 Key: SWAP-25
                 URL: http://jira.jboss.com/jira/browse/SWAP-25
             Project: PortletSwap
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         Assigned To: Julien Viet


Tutorial portlet is out of date as MyFaces is not bundled anymore.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 12:23:49 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 7 Aug 2007 12:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SWAP-26) Add RI JSF portlet for
	AS 4.2
Message-ID: <24942180.1186503829752.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add RI JSF portlet for AS 4.2
-----------------------------

                 Key: SWAP-26
                 URL: http://jira.jboss.com/jira/browse/SWAP-26
             Project: PortletSwap
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portlets
            Reporter: Chris Laprun
         Assigned To: Julien Viet


Add a JSF portlet example showing how to use JSF RI to create a 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 lists.jboss.org  Tue Aug  7 12:58:49 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 7 Aug 2007 12:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4587)
 NoClassDefFoundError java.lang.System
In-Reply-To: <6030030.1185874069379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16168483.1186505929456.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4587?page=comments#action_12371354 ] 
            
Aleksandar Kostadinov commented on JBAS-4587:
---------------------------------------------

Issue seems to have gone away somewhere after build  25 
http://dev45.qa.atl.jboss.com:8585/hudson/job/JBoss_AS_Testsuite_HEAD-jdk15/25/

I'll keep it until you tell me so you could investigate.

> NoClassDefFoundError java.lang.System
> -------------------------------------
>
>                 Key: JBAS-4587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4587
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions:  JBossAS-5.0.0.Beta3
>         Environment: QA Lab, VM, Sun JDK 1.5
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Scott M Stark
>         Attachments: server_log.zip, server_log_1.zip
>
>
> In the QA Lab we come across an issue when trying to run the JBoss AS test suite on VMs (see trace level log bolow). Consequences are that minimal server doesn't shutdown and test suite fails on starting the all configuration.
> To reproduce:
> Can be reproduced on a VM with sun jdk15 versions including 1.5.0_12. 
> Try ssh to qa01.qa.atl.jboss.com. On any issue ask in jboss-qa-internal at redhat.com or #jbossqa
> Checkout trunk.
> build/build.sh
> testsuite/build.sh jboss-minimal-tests
> The issue doesn't occur on physical machines as well jrockit is not affected.
> If that could be of any help I've found two issues with java.lang.System not found and gcj.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6371479
> http://www.linuxhelpforum.com/showthread.php?t=809687
> 2 server trace logs attached. Part of log see below:
> 2007-07-31 05:04:11,222 DEBUG [org.jboss.deployers.plugins.deployers.DeployersIm
> pl] Fully Undeployed vfsfile:/qa/services/hudson/hudson_workspace/workspace/JBos
> s_AS_Testsuite_HEAD-jdk15/src/build/output/jboss-5.0.0.Beta3/server/minimal/depl
> oy/shutdown.sar
> 2007-07-31 05:04:11,223 TRACE [org.jboss.system.server.profileservice.hotdeploy.
> HDScanner] End deployment scan
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=0
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=1
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,224 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,225 ERROR [STDERR] Exception in thread "ExitOnShutdown"
> 2007-07-31 05:04:11,226 ERROR [STDERR] java.lang.NoClassDefFoundError: java/lang
> /System
> 2007-07-31 05:04:11,226 ERROR [STDERR]  at org.jboss.test.jmx.shutdown.ExitOnShu
> tdown$1.run(ExitOnShutdown.java:52)
> 2007-07-31 05:04:11,227 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 lists.jboss.org  Tue Aug  7 13:54:49 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 7 Aug 2007 13:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26384063.1186509289437.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371355 ] 
            
Imran Naqvi commented on GPD-130:
---------------------------------

yes th array should only contain ConfigInfoElements. But the following lines in ConfigInfoElements.getConfigInfoElements() always returns a class cast exception:

return (ConfigInfoElement[])configInfoElements.toArray(new Object[configInfoElements.size()]);

this is because we are trying to directly cast from Object[] to ConfigInfoElement[]. Even though every element in Object[] is a ConfigInfoElement, it is still not allowed to have two references to an array of different types. Instead something like this would work:

                                          ConfigInfoElement[] elements = new ConfigInfoElement[configInfoElements.size()];
		for (int i = 0; i < configInfoElements.size(); i++)
			elements[i] = (ConfigInfoElement) this.configInfoElements.get(i);

		return elements;

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 14:07:09 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 14:07:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1623) Create "Admin"
 icon for the different themes for the new admin portlet mode
Message-ID: <19138744.1186510029362.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create "Admin" icon for the different themes for the new admin portlet mode
---------------------------------------------------------------------------

                 Key: JBPORTAL-1623
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1623
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.6.3 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 lists.jboss.org  Tue Aug  7 14:26:49 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 14:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1624) Create icon for
 the admin
 mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
Message-ID: <5089473.1186511209298.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create icon for the admin mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
--------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1624
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1624
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 14:34:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 14:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1161) PojoCache
 loadtime example failure
In-Reply-To: <17873568.1186438129330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15232704.1186511689335.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1161?page=all ]

Jason T. Greene resolved JBCACHE-1161.
--------------------------------------

    Resolution: Done

fixed, retaged

> PojoCache loadtime example failure
> ----------------------------------
>
>                 Key: JBCACHE-1161
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1161
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Jason T. Greene
>
> The following exceptions occurs when running the example under JBossCache-pojo-2.0.0.GA\examples\PojoCache\loadtime
> "build.bat compile" &  "build.bat run.loadtime.example"
>      [java] Exception in thread "main" java.lang.IllegalArgumentException: PojoCache.putObject(): Object type is neither  aspectized nor Serializable nor an array of prim
> itives. Object class name is examples.Student
>      [java]     at org.jboss.cache.pojo.util.AopUtil.checkObjectType(AopUtil.java:125)
>      [java]     at org.jboss.cache.pojo.interceptors.CheckNonSerializableInterceptor.invoke(CheckNonSerializableInterceptor.java:36)
>      [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
>      [java]     at org.jboss.cache.pojo.interceptors.CheckIdInterceptor.invoke(CheckIdInterceptor.java:33)
>      [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
>      [java]     at org.jboss.cache.pojo.interceptors.PojoBeginInterceptor.invoke(PojoBeginInterceptor.java:36)
>      [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
>      [java]     at test.examples.StudentMaintTest.testPropagation(StudentMaintTest.java:99)
>      [java]     at test.examples.StudentMaintTest.main(StudentMaintTest.java:145)
>      [java] Java Result: 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 lists.jboss.org  Tue Aug  7 14:46:49 2007
From: jira-events at lists.jboss.org (Rajesh Rajasekaran (JIRA))
Date: Tue, 7 Aug 2007 14:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1160)
 org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
In-Reply-To: <19125763.1186437829351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21097310.1186512409723.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1160?page=comments#action_12371365 ] 
            
Rajesh Rajasekaran commented on JBCACHE-1160:
---------------------------------------------

Jason, this is the other issue with the 2.0.0.GA release.

> org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
> -------------------------------------------------------------------------
>
>                 Key: JBCACHE-1160
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1160
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Jason T. Greene
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/20070806045019/results/org/jboss/cache/pojo/rollback/InMemoryTxUndoTest(tcp).html
> The test attaches a second Person object to an existing node (Person object) within the scope of a transaction and rolls back.
> The following exception occurs when trying to retrieve the first object.
> testSimpleTxWithRollback3	
> Error	org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4
> org.jboss.cache.pojo.PojoCacheAlreadyDetachedException: org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4 at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.verifyAttached(CacheFieldInterceptor.java:177) at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.invoke(CacheFieldInterceptor.java:153) at org.jboss.cache.pojo.test.Person$age_Get.invokeNext(Person$age_Get.java) at org.jboss.cache.pojo.test.Person.age_r_$aop(Person.java) at org.jboss.cache.pojo.test.Person.getAge(Person.java:76) at org.jboss.cache.pojo.rollback.InMemoryTxUndoTest.testSimpleTxWithRollback3(InMemoryTxUndoTest.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:03:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Tue, 7 Aug 2007 15:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-868)
 java.lang.IllegalArgumentException: Unable to find operation XYZ for
 dependent beans in seperate jars
In-Reply-To: <5235901.1170897390091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10269495.1186513429387.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-868?page=comments#action_12371368 ] 
            
William DeCoste commented on EJBTHREE-868:
------------------------------------------

Could you please open a support ticket so that we can track your problem via the ticket instead of this closed JIRA?

> java.lang.IllegalArgumentException: Unable to find operation XYZ for dependent beans in seperate jars
> -----------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-868
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-868
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.0 GA
>
>
> java.lang.IllegalArgumentException: Unable to find operation sayHello()
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
> 	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
> 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
> 	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:263)
> 	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:999)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:454)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261)
> Caused by: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:231)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy89.sayHello(Unknown Source)
> 	at org.jboss.ejb3.test.dependency.ABean.getHelloB(ABean.java:18)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:18:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 15:18:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21539574.1186514330822.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371371 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

Hm, I think the roblem is that I am using new Object[configInfoElements.size()] as the parameter for toArray. This should be new ConfigInfoElement[configInfoElements.size()]

I will change the paramter and commit. It would be great if you could test if it works

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:22:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 15:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4744251.1186514569646.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371372 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

Oh, in case you didn't remark it yet, I refactored the ConfigInfoElement class. It is called GenericElement now

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:25:06 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 15:25:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6826272.1186514706900.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-130?page=all ]

Koen Aers resolved GPD-130.
---------------------------

    Resolution: Done

Scream if it doesn't work! ;-)

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 16:01:53 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 16:01:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1625) Portlet mode
 "admin" for portlet administration
Message-ID: <32179551.1186516913488.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portlet mode "admin" for portlet administration
-----------------------------------------------

                 Key: JBPORTAL-1625
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1625
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 16:01:55 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 16:01:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13216473.1186516915019.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Scott M Stark updated JBMICROCONT-123:
--------------------------------------

               Issue Type: Bug  (was: Task)
    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071717
                 Assignee: Scott M Stark  (was: Ales Justin)

This is actually a bug as this method does not work. See the org.jboss.test.classinfo.test.ClassInfoArrayTest.testArrayType() test.


> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For:  JBossMC-2.2.0.GA
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Tue Aug  7 16:07:53 2007
From: jira-events at lists.jboss.org (James Cobb (JIRA))
Date: Tue, 7 Aug 2007 16:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (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: <12188165.1186517273987.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

James Cobb reassigned JBFORUMS-128:
-----------------------------------

    Assignee: Meriah Garrett  (was: James Cobb)

The global catch all for the forums project.

> 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
>          Components: Forum View Layer, Portlet Productization
>            Reporter: Sohil Shah
>         Assigned To: Meriah Garrett
>             Fix For: 1.0.1 RC
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 16:09:49 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 16:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1622) Implement
 "admin" portlet mode
In-Reply-To: <22138593.1186502329360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13023950.1186517389308.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Julien Viet resolved JBPORTAL-1622.
-----------------------------------

    Resolution: Done

> Implement "admin" portlet mode
> ------------------------------
>
>                 Key: JBPORTAL-1622
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1622
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 17:21:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 17:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-390) Update jboss retro
 site on jboss.org.
In-Reply-To: <31686227.1183489257627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7672113.1186521709313.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-390?page=all ]

Paul Gier closed JBBUILD-390.
-----------------------------

    Resolution: Done

Some basic documentation has been added to the site, and downloadable zip files have been added.

> Update jboss retro site on jboss.org.
> -------------------------------------
>
>                 Key: JBBUILD-390
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-390
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: JBossRetro-1.1.2.GA
>
>
> Update jbossretro on jboss.org (http://labs.jboss.com/jbossretro).  The site content should be generated by maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 17:57:55 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Tue, 7 Aug 2007 17:57:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
Message-ID: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>

maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
----------------------------------------------------------------------------------

                 Key: JBAOP-453
                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: maven 2
            Reporter: Anders Andersen


In order to use the plugin I have to add the following dependencies to the client artifact dependency list.

    <dependency>
      <groupId>org.jboss.maven.plugins</groupId>
      <artifactId>maven-jbossaop-plugin</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-aop</artifactId>
      <version>2.0.0.alpha2</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-common</artifactId>
      <version>4.0.2</version>
    </dependency>
    <dependency>
      <groupId>concurrent</groupId>
      <artifactId>concurrent</artifactId>
      <version>1.3.4</version>
    </dependency>

This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.

See lists below.
I think the statement
      cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
is wrong.

I tried to include only project.getPluginArtifacts(), but it gave me a NPE
So I am not 100% sure what the code solution should be
but it is not good to having maven artifacts in the resulting dependency list of the client-artifact

list: (resulting depenency list)
The ** marked should not be there

**/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
/Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
/Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
/Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
/Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
/Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
/Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
/Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
/Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
/Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
/Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
/Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
/Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
/Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
/Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
/Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
/Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
/Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
/Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
/Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
/Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
/Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
/Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
/Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
/Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
/Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
/Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
/Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
/Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
/Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
/Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
/Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
/Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
/Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
/Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
/Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
/Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
/Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
/Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
/Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
/Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
/Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
/Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
/Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
/Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
/Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
**/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
/Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
/Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
/Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
/Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
/Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
/Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
/Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Tue Aug  7 18:18:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Tue, 7 Aug 2007 18:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10086541.1186525129403.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371395 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

hi all - sorry ive been ill for a few days and it has delayed my verification of this. everything looks to be working fine. 

as far as my intentions with MAX_VALUE, i was thinking of the difference of a Priority 1 problem vs a Priority 2 problem. it may or may not make sense in that context but certainly as i began working with using the priorities it became more and more obvious that descending priorities was very counter-intuitive. i like the use of 0 as the default much better! 

thanks to everyone for the great discussion. i hope this helps make it easier for people to make extensions!

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 18:18:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Tue, 7 Aug 2007 18:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-111) Add ability to forward
 and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33406272.1186525129559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Matthew Sandoz closed GPD-111.
------------------------------


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 20:19:49 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 20:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19639838.1186532389452.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Scott M Stark updated JBMICROCONT-123:
--------------------------------------

    Comment: was deleted

> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For:  JBossMC-2.2.0.GA
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Tue Aug  7 20:28:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 20:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
Message-ID: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Node.clearData() does not rollback correctly
--------------------------------------------

                 Key: JBCACHE-1162
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Jason T. Greene
         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 lists.jboss.org  Tue Aug  7 20:28:49 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 20:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11656263.1186532929710.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Scott M Stark reassigned JBMICROCONT-123:
-----------------------------------------

    Assignee: Ales Justin  (was: Scott M Stark)

> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>            Priority: Minor
>             Fix For:  JBossMC-2.2.0.GA
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Tue Aug  7 20:34:00 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 20:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-202) Primative
 arrays are not
 handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
Message-ID: <17430949.1186533240797.JavaMail.jira@cloud.prod.atl2.jboss.com>

Primative arrays are not handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
----------------------------------------------------------------------------------------------

                 Key: JBMICROCONT-202
                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-202
             Project: JBoss MicroContainer
          Issue Type: Bug
          Components: MetaData
    Affects Versions:  JBossMC_2_0_0 Beta3
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossMC-2.0.0.Beta4


When looking at obtaining MetaType/MetaValues for primative arrays I see problems with the primitive array type name ("[char" vs "[C") and attempts to cast to Object[] in DefaultMetaValueFactory. The referenced forum discusses the 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 lists.jboss.org  Tue Aug  7 20:35:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 20:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
In-Reply-To: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13361121.1186533349345.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1162?page=all ]

Jason T. Greene updated JBCACHE-1162:
-------------------------------------

    Fix Version/s: 2.0.0.GA

> Node.clearData() does not rollback correctly
> --------------------------------------------
>
>                 Key: JBCACHE-1162
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 21:40:00 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 21:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1064) "->" notation
 for predicates missing in documentation
In-Reply-To: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23830433.1186537200895.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

-> is now deprecated, its not just needed now.

Person( girlAge : age, sex = "F" )
Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' ) 

is now, notice the boyAge does not need binding, as it will determine and bind "age" as part of the autovivification process.
Person( girlAge : age, sex = "F" )
Person( eval( girlAge == age + 2 ), sex = 'M' ) 

You can ofcourse still still bind the boyAge, but generally its not preferred any more. Basically predicates where where focused on a single field are no longer needed as we determine the used and bound fields on the fly, we also now call then inline-eval. Predicate, while the traditional name, was dropped, this is partly in preparation for when we start to support backward chaining and will use the term predicate in the prolog sense.
Person( boyAge : age, eval( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' ).

I'll close this one off in a day or so, if I don't hear any further feedback.

> "->" notation for predicates missing in documentation
> -----------------------------------------------------
>
>                 Key: JBRULES-1064
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>            Priority: Minor
>
> the notation "->" for adressing complex terms is missing from 4.0.0 documentation.
> It has been "return value operator" in 3.0.6:
> <quoted from 3.0.6>
> Example 3.13. Return Value operator
> Person( girlAge : age, sex = "F" )
> Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
> </quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 22:15:51 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Aug 2007 22:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2299) OutOfMemory error when
 repetatively deploying and undeploying with 10 minute interval
Message-ID: <115029.1186539351637.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBAS-2299.
---------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
       Resolution: Rejected

This is a Jakarta commons issue... not a JBoss issue

I have created a testcase that replicates this and submitted to them...  

https://issues.apache.org/jira/browse/BEANUTILS-291


There is nothing else we can do about this now.. we could just wait and see if they will fix it!

> 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
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Tue Aug  7 22:26:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 22:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
In-Reply-To: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24045604.1186540009444.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1162?page=all ]

Jason T. Greene resolved JBCACHE-1162.
--------------------------------------

    Resolution: Done

> Node.clearData() does not rollback correctly
> --------------------------------------------
>
>                 Key: JBCACHE-1162
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 22:26:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 22:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
In-Reply-To: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2155866.1186540009557.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1162?page=all ]

Jason T. Greene closed JBCACHE-1162.
------------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> Node.clearData() does not rollback correctly
> --------------------------------------------
>
>                 Key: JBCACHE-1162
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 22:26:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 22:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1160)
 org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
In-Reply-To: <19125763.1186437829351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19110905.1186540009726.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1160?page=all ]

Jason T. Greene closed JBCACHE-1160.
------------------------------------

    Fix Version/s: 2.0.0.GA
       Resolution: Done

> org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
> -------------------------------------------------------------------------
>
>                 Key: JBCACHE-1160
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1160
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/20070806045019/results/org/jboss/cache/pojo/rollback/InMemoryTxUndoTest(tcp).html
> The test attaches a second Person object to an existing node (Person object) within the scope of a transaction and rolls back.
> The following exception occurs when trying to retrieve the first object.
> testSimpleTxWithRollback3	
> Error	org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4
> org.jboss.cache.pojo.PojoCacheAlreadyDetachedException: org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4 at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.verifyAttached(CacheFieldInterceptor.java:177) at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.invoke(CacheFieldInterceptor.java:153) at org.jboss.cache.pojo.test.Person$age_Get.invokeNext(Person$age_Get.java) at org.jboss.cache.pojo.test.Person.age_r_$aop(Person.java) at org.jboss.cache.pojo.test.Person.getAge(Person.java:76) at org.jboss.cache.pojo.rollback.InMemoryTxUndoTest.testSimpleTxWithRollback3(InMemoryTxUndoTest.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 01:47:49 2007
From: jira-events at lists.jboss.org (Tong Lee (JIRA))
Date: Wed, 8 Aug 2007 01:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1065) Unable to return
 Declaration for identifier
Message-ID: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to return Declaration for identifier
-------------------------------------------

                 Key: JBRULES-1065
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Java 1.6
            Reporter: Tong Lee
         Assigned To: Mark Proctor


I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:

Fact/bean object code:
public class Record {
private String abc;
private String xyz;
public String getAbc()...
public String getXyz()...
...
}

DRL code:
rule "..."
  when
    $record : Record ( abc == xyz)
  then
    ....
end

The PackageBuilder can not resolve the "xyz"

I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
rule "..."
  when
    r: Record ( )
    $record : Record ( abc == r.xyz)
  then
    ....
end

Any feedback with this is greatly 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 lists.jboss.org  Wed Aug  8 03:39:49 2007
From: jira-events at lists.jboss.org (Tuomas Kiviaho (JIRA))
Date: Wed, 8 Aug 2007 03:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5213894.1186558789698.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-992?page=comments#action_12371406 ] 
            
Tuomas Kiviaho commented on JBRULES-992:
----------------------------------------

JavaDialect seems to have been fixed in trunk. There has been some development around jsr199 at Commons JCI that would make both jdt and jalopy optional thus reducing the external dependencies even further.

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Mark Proctor
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Wed Aug  8 04:36:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 04:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6432042.1186562209472.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371409 ] 
            
Ross McDonald commented on GPD-134:
-----------------------------------

Hi sorry for the delay, I never tried this with HSQL, you are probably right about it being a more general JBPM issue.

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 04:38:49 2007
From: jira-events at lists.jboss.org (Matt Drees (JIRA))
Date: Wed, 8 Aug 2007 04:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1066)
 org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not
 serializable
Message-ID: <23034283.1186562329494.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not serializable
---------------------------------------------------------------------------------------

                 Key: JBRULES-1066
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1066
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: seam cvs (2007-08-05), which includes drools 4.0.0.GA, I believe
            Reporter: Matt Drees
         Assigned To: Mark Proctor
            Priority: Minor


I sometimes get a java.io.NotSerializableException: org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction when restarting my seam webapp.  It seems that the problem is simply that WorkingMemoryReteAssertAction doesn't implement Serializable.  This email (http://osdir.com/ml/java.drools.user/2006-12/msg00163.html) seems to indicate that it should, but it apparently hasn't been 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 lists.jboss.org  Wed Aug  8 04:42:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 04:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12489081.1186562569342.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371410 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

Hi Koen, no problem there, as you said I figured out how to fix this by naming every transition.  Is the upcoming release the one with support for custom nodes ? Is there a reference with info about it, I am very keen for more details :-)

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 04:59:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Aug 2007 04:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-519) Replace
 BoundedList/List with java.util(.concurrent) class
In-Reply-To: <25866563.1180426750122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13446546.1186563589407.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

removed List

> Replace BoundedList/List with java.util(.concurrent) class
> ----------------------------------------------------------
>
>                 Key: JGRP-519
>                 URL: http://jira.jboss.com/jira/browse/JGRP-519
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> E.g. BoundedList could be a subclass of java.util.LinkedList

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:28:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10760341.1186565329791.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371422 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

yes, but there is not yet a lot of info except some forum entries an jira issues. 

i plan to write an article about it soon.

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:46:49 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 8 Aug 2007 05:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23264550.1186566409555.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Stale Pedersen reassigned JBAOP-453:
------------------------------------

    Assignee: Stale Pedersen

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 05:57:31 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 05:57:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1027) Timeout method
 gets called with an unspecified caller identity
Message-ID: <6643972.1186567051460.JavaMail.jira@cloud.prod.atl2.jboss.com>

Timeout method gets called with an unspecified caller identity
--------------------------------------------------------------

                 Key: EJBTHREE-1027
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1027
             Project: EJB 3.0
          Issue Type: Bug
          Components: Security
    Affects Versions: AS 4.2.1.GA
            Reporter: Carlo de Wolf


Having a secured bean with a timeout method with @PermitAll, but without an unauthenticatedIdentity will lead to a 'random' identity being used to call the method or no identity at all. The last one leads to EJBAccessExceptions.

Spec 18.2.2:
"Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity."

We must disallow all calls to a timeout method if unauthenticatedIdentity is not 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 lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1027) Timeout method
 gets called with an unspecified caller identity
In-Reply-To: <6643972.1186567051460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <215766.1186567129426.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1027?page=comments#action_12371428 ] 
            
Carlo de Wolf commented on EJBTHREE-1027:
-----------------------------------------

Unit test: timer

> Timeout method gets called with an unspecified caller identity
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1027
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1027
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: AS 4.2.1.GA
>            Reporter: Carlo de Wolf
>
> Having a secured bean with a timeout method with @PermitAll, but without an unauthenticatedIdentity will lead to a 'random' identity being used to call the method or no identity at all. The last one leads to EJBAccessExceptions.
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity."
> We must disallow all calls to a timeout method if unauthenticatedIdentity is not 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 lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <19612880.1186567129517.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers closed GPD-126.
-------------------------


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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <5982020.1186567129592.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers closed GPD-127.
-------------------------


> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7301572.1186567129765.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-128?page=all ]

Koen Aers closed GPD-128.
-------------------------


> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Wed Aug  8 06:00:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
In-Reply-To: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1897555.1186567250239.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-129?page=all ]

Koen Aers closed GPD-129.
-------------------------


i am getting ready for the release, feel free to reopen if this is still a problem

> ConfigInfoElementDomAdapter doesnt define node types
> ----------------------------------------------------
>
>                 Key: GPD-129
>                 URL: http://jira.jboss.com/jira/browse/GPD-129
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:
> <?xml version="1.0"?>
> <process-definition name="Movie" version="11">
> <start-state name="Start">
> <transition to="Get MPEG Properties" />
> 	</start-state>
> <node name="Get MPEG Properties">
> 			<action class="SomeActionHandler"><send>010901</send>
> <keys>
> 		<entry>
>                                             <key>VarName</key>
>                                             <value>1122</value>
>                                 </entry>
> 	</keys>
> 	<receive>
> 		<element>030101</element>
> 		<element>030102</element>	
> 	</receive>
> </action>
> 				<transition to="End"/>	</node>
> <end-state name="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 lists.jboss.org  Wed Aug  8 06:00:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-130) Class Cast exception in
 ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25636536.1186567250359.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-130?page=all ]

Koen Aers closed GPD-130.
-------------------------


i am getting ready for the cr release, feel free to reopen if this is still a problem

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 06:00:50 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 8 Aug 2007 06:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8719812.1186567250539.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371431 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

ive added a few dependencies into the plugin so you'll only have to include the aop plugin in the pom file. im not sure if its possible to prevent the modules that the plugin depends on not to be included, but ill check it up.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 06:04:08 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:04:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25843504.1186567448284.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers closed GPD-78.
------------------------

    Resolution: Done

i am closing this again as i cannot see the exact problem. feel free to reopen if still a problem. also it would be good to attach a processdefinition producing the problem in that case

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  8 06:05:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-24) add convenient way to
 create loop transitions
In-Reply-To: <28729967.1168955216880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20993963.1186567549680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-24?page=all ]

Koen Aers updated GPD-24:
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
                       (was: jBPM JPDL Designer 3.1.0.CR)

> add convenient way to create loop transitions
> ---------------------------------------------
>
>                 Key: GPD-24
>                 URL: http://jira.jboss.com/jira/browse/GPD-24
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> the current workaround is to write the self-transition in xml.
> but this results in some *really* weird bendpoints when going back to the graphical 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 lists.jboss.org  Wed Aug  8 06:47:54 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 06:47:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30205959.1186570074975.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371443 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

Hi Koen,

I hope you don't think me rude for asking, can I email you directly with a couple of questions, I am implementing several large processes with JBPM JPDL for my company, they will be part of a project we are working on with British Airways, and I need a little help, I would hope not to take too much of your time, or perhaps you can suggest someone else who may be able to help ?  I only ask because although the forum is generally very good, I am waiting for an answer regarding mail and actors within eclipse 'http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115230', as I am not very clear on actors other than initiator.  I have two other questions which I could do with help on also.

Thanks for your time,

regards,

Ross

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 07:00:50 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 8 Aug 2007 07:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBWEB-88) Http11NioProtocol
 randomaly mix headers between requests
Message-ID: <18631260.1186570850236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-88?page=all ]

Thomas Diesler moved JBWS-1781 to JBWEB-88:
-------------------------------------------

              Project: JBoss Web  (was: JBoss Web Services)
                  Key: JBWEB-88  (was: JBWS-1781)
    Affects Version/s:     (was: jbossws-2.0.0)

> Http11NioProtocol randomaly mix headers between requests
> --------------------------------------------------------
>
>                 Key: JBWEB-88
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-88
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Running jbossws-2.0.0.GA on jboss 4.2, Redhat AS 4 update 4
>            Reporter: Tomer Cohen
>
> This version (as it relay on tomcat 6.0.10) suffer from http://issues.apache.org/bugzilla/show_bug.cgi?id=42701 which essentially makes the use of Nio useless.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 07:26:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1004)
 EJBRegistrationDeployer doesn't come up
In-Reply-To: <8824276.1183495011230.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21132280.1186572409312.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved EJBTHREE-1004.
-------------------------------------

    Resolution: Done

> EJBRegistrationDeployer doesn't come up
> ---------------------------------------
>
>                 Key: EJBTHREE-1004
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1004
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug  8 07:31:56 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-615) NPE in Embedded
 Jboss when getCallerPrincipal method on SessionContext
Message-ID: <31352589.1186572716244.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf reassigned EJBTHREE-615:
--------------------------------------

    Assignee: Carlo de Wolf

> NPE in Embedded Jboss when getCallerPrincipal method on SessionContext
> ----------------------------------------------------------------------
>
>                 Key: EJBTHREE-615
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-615
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Nicolai ?dum
>         Assigned To: Carlo de Wolf
>         Attachments: BugReportInterceptor.java
>
>
> The bug is pretty easy to create.
> Modify the CalculaterBean in the security example that is distributed with JBoss embedded like this
> import javax.annotation.Resource;
> import java.security.Principal;
> import javax.ejb.SessionContext;
> ..
> public class CalculatorBean implements Calculator
> {
> @Resource SessionContext ctx;	
> @RolesAllowed({"student"})
> public int subtract(int x, int y)
> {
> Principal caller = ctx.getCallerPrincipal(); //Nullpointer
> return x - y;
> }
> The exception
> full stacktrace: 
> javax.ejb.EJBException: java.lang.NullPointerException 
> at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69) 
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83) 
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:167) 
> at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:100) 
> 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.localInvoke(StatelessContainer.java:181) 
> at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79) 
> at $Proxy15.getSubscriberDetails(Unknown Source) 
> Another user has reported that is is possible to get the principal from org.jboss.security.SecurityAssociation.getPrincipal(), but not from the Session 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 lists.jboss.org  Wed Aug  8 07:33:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-615) NPE in Embedded
 Jboss when getCallerPrincipal method on SessionContext
Message-ID: <21885055.1186572829667.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved EJBTHREE-615.
------------------------------------

    Resolution: Deferred

EJB 3 embedded is no longer supported.

> NPE in Embedded Jboss when getCallerPrincipal method on SessionContext
> ----------------------------------------------------------------------
>
>                 Key: EJBTHREE-615
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-615
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Nicolai ?dum
>         Assigned To: Carlo de Wolf
>         Attachments: BugReportInterceptor.java
>
>
> The bug is pretty easy to create.
> Modify the CalculaterBean in the security example that is distributed with JBoss embedded like this
> import javax.annotation.Resource;
> import java.security.Principal;
> import javax.ejb.SessionContext;
> ..
> public class CalculatorBean implements Calculator
> {
> @Resource SessionContext ctx;	
> @RolesAllowed({"student"})
> public int subtract(int x, int y)
> {
> Principal caller = ctx.getCallerPrincipal(); //Nullpointer
> return x - y;
> }
> The exception
> full stacktrace: 
> javax.ejb.EJBException: java.lang.NullPointerException 
> at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69) 
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83) 
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:167) 
> at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:100) 
> 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.localInvoke(StatelessContainer.java:181) 
> at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79) 
> at $Proxy15.getSubscriberDetails(Unknown Source) 
> Another user has reported that is is possible to get the principal from org.jboss.security.SecurityAssociation.getPrincipal(), but not from the Session 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 lists.jboss.org  Wed Aug  8 07:36:00 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-972)
 sessionContext.getBusinessObject(null) should throw IllegalStateException
In-Reply-To: <23520376.1179840652438.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13744084.1186572960473.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved EJBTHREE-972.
------------------------------------

    Resolution: Done

> sessionContext.getBusinessObject(null) should throw IllegalStateException
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-972
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-972
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug  8 07:45:49 2007
From: jira-events at lists.jboss.org (Shahad Ahmed (JIRA))
Date: Wed, 8 Aug 2007 07:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1067) Allow RuleAgent
 to take a RuleBaseConfiguration to configure the RuleBase it creates
Message-ID: <28877644.1186573549478.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow RuleAgent to take a RuleBaseConfiguration to configure the RuleBase it creates
------------------------------------------------------------------------------------

                 Key: JBRULES-1067
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1067
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Sun JRE 1.5_09
            Reporter: Shahad Ahmed
         Assigned To: Mark Proctor


Extend the API to allow a RuleAgent to use a  RuleBaseConfiguration object to configure the RuleBase it creates. For example, this will allow a user to specfiy options like Sequental mode etc when creating a RuleBase using a RuleAgent.

I know that you can set RuleBase options for all RuleBases by setting the appropriate System properties when calling the java VM, but it would be nice to be able to set these individually via the API for each RuleBase created using a RuleAgent. I guess this could be done fairly easily by adding an extra constructor(s) to RuleAgent that takes a RuleBaseConfiguration object -- rbConfig, say -- and in RuleAgent when it creates a new RuleBase instead of just using RulebaseFactory.newRuleBase() use RulebaseFactory.newRuleBase(rbConfig) 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 lists.jboss.org  Wed Aug  8 07:53:58 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:53:58 -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: <509158.1186574038602.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: AS 4.2.2.GA
                   EJB 3.0 RC11 - FD
                   AS 4.2.1.GA
                   AS 4.2.0 GA
                       (was: Branch_4_2)

Was already fixed.

> 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 RC11 - FD, AS 4.2.0 GA, AS 4.2.1.GA, AS 4.2.2.GA
>
>
> 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 lists.jboss.org  Wed Aug  8 07:53:58 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:53:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15232354.1186574038831.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved EJBTHREE-712.
------------------------------------

    Resolution: Done

> 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: AS 4.2.2.GA, EJB 3.0 RC11 - FD, AS 4.2.1.GA, AS 4.2.0 GA
>
>
> 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 lists.jboss.org  Wed Aug  8 08:07:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 08:07:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-989) Can't inject
 resources of type URL
In-Reply-To: <4013988.1181204294674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23804878.1186574869576.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved EJBTHREE-989.
------------------------------------

    Resolution: Done

> Can't inject resources of type URL
> ----------------------------------
>
>                 Key: EJBTHREE-989
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-989
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> All constructs leading into injection of an URL do not work.
> @Stateless
> @Remote(ResUrlChecker.class)
> @Resources({
>    @Resource(name="url3", type=java.net.URL.class, mappedName="http://localhost/url3")
> })
> public class ResUrlCheckerBean implements ResUrlChecker
> {
>    @Resource(mappedName="http://localhost")
>    private URL url1;
>    
>    // coming in via res-url
>    @Resource(name="url2")
>    private URL url2;
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 08:12:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 08:12:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25760596.1186575169446.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371463 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

No please stick to the public user forum for these types of questions, they may be of interest to the entire community. If your questions are difficult to ask publicly for various reasons, consider a support contract or attending a public training.

Regards,
Koen

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 08:16:04 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 08:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11731410.1186575364241.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371465 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

sure no problem,

Ross

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 08:24:50 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 08:24:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-847) exception during
 destroy of
 stateful bean then @SecurityDomain is defined for seam bean
Message-ID: <30245751.1186575890089.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved EJBTHREE-847.
------------------------------------

    Resolution: Rejected

You must also specify an unauthenticatedIdentity in your login-config.xml.

> exception during destroy of stateful bean then @SecurityDomain is defined for seam bean
> ---------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-847
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-847
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: jboss4.0.4GA+EJB3RC8+seam1.1.0.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Carlo de Wolf
>
> With seam 1.1.0 we have an issue during destroying of bean. 
> Stateful bean is defined as
> @Stateful
> @SerializedConcurrentAccess
> @Scope(ScopeType.SESSION)
> @Name("studioAuditTracking")
> @Interceptors(SeamInterceptor.class)
> @SecurityDomain("OurDomain")
> public class StudioAuditTrackingBean implements Serializable, StudioAuditTracking 
> It works perfect, but during destroy there is an error. And log files full of such errors.
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) javax.ejb.EJBAccessException: Authentication failure
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:71)
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) at
> I tried to set idleTimeoutSeconds to the same value like in web session timeout following WIKI, but still the same issue.
> it seems that security principal is not propagated during destroy. 
> after putting logging on debug level found the cause of an issue.
> Problem is that in tomcat separate thread is running to destroy expired sessions. But logon credentials are associated with another thread - which is served a connection from browser.
> So ContainerBackgroundProcessor[StandardEngine[jboss.web]]: is expiring session and calling seamListener.sessionDestroyed().
> which is trying to destroy bean which is protected by @SecurityDomain annotation. SecurityInterceptor tries to find principal - doesn't find it and do login() with null credentials (because this thread doesn't have associated credentials). And exception occurs. See debug logging below: 
> 2007-01-26 11:23:43,493 639138 DEBUG [org.apache.catalina.session.ManagerBase] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Start expire sessions StandardManager at 1169807023493 sessioncount 1
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Lifecycle] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) End of session, destroying contexts
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Lifecycle] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying conversation contexts: []
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Lifecycle] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying session context
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preDestroyContext.SESSION
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Contexts] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying: locale
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.contexts.Contexts] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying: studioErrorTracking
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preDestroy.studioErrorTracking
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preSetVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.postSetVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,514 639159 WARN [be.certipost.am.utils.loginmodule.AMBasedLoginModule] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Password was null and has been set to empty String!!!
> 2007-01-26 11:23:43,542 639187 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Level, false)
> 2007-01-26 11:23:43,542 639187 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,542 639187 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Level)
> 2007-01-26 11:23:43,543 639188 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,543 639188 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Logger, false)
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Logger)
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,553 639198 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Category, false)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Category)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Priority, false)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Priority)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Level, false)
> 2007-01-26 11:23:43,570 639215 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,570 639215 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Level)
> 2007-01-26 11:23:43,571 639216 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,571 639216 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,571 639216 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.logging.XLevel, false)
> 2007-01-26 11:23:43,582 639227 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,582 639227 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.logging.XLevel)
> 2007-01-26 11:23:43,583 639228 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,583 639228 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,583 639228 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Logger, false)
> 2007-01-26 11:23:43,594 639239 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,594 639239 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Logger)
> 2007-01-26 11:23:43,594 639239 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,595 639240 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,595 639240 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Priority, false)
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Priority)
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,613 639258 DEBUG [be.certipost.am.utils.jboss.Utils] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) flushing principal null for security domain CertiOne
> 2007-01-26 11:23:43,613 639258 DEBUG [be.certipost.am.utils.jboss.Utils] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Flushing principal for user null for security domain CertiOne on server 10.100.204.101
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.LinkRef, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.Reference, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.util.Vector, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.StringRefAddr, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.RefAddr, false)
> 2007-01-26 11:23:43,650 639295 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.adaptor.rmi.RMIAdaptor, false)
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.adaptor.rmi.RMIAdaptor)
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,660 639305 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.adaptor.rmi.RMIAdaptorExt, false)
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,663 639308 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.io.IOException, false)
> 2007-01-26 11:23:43,663 639308 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ReflectionException, false)
> 2007-01-26 11:23:43,663 639308 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.InstanceNotFoundException, false)
> 2007-01-26 11:23:43,664 639309 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.IntrospectionException, false)
> 2007-01-26 11:23:43,664 639309 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.MBeanRegistrationException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.MBeanException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.InvalidAttributeValueException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.AttributeNotFoundException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ListenerNotFoundException, false)
> 2007-01-26 11:23:43,672 639317 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.NotCompliantMBeanException, false)
> 2007-01-26 11:23:43,677 639322 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.InstanceAlreadyExistsException, false)
> 2007-01-26 11:23:43,679 639324 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ObjectName, false)
> 2007-01-26 11:23:43,680 639325 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.AttributeList, false)
> 2007-01-26 11:23:43,680 639325 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ObjectInstance, false)
> 2007-01-26 11:23:43,680 639325 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.NotificationListener, false)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.NotificationFilter, false)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.adaptor.rmi.RMINotificationListener, false)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.adaptor.rmi.RMINotificationListener)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.Attribute, false)
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.MBeanInfo, false)
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.QueryExp, false)
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.util.Set, false)
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.ClientContainer, false)
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.ClientContainer)
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.ClientMethodInterceptor, false)
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.ClientMethodInterceptor)
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.Interceptor, false)
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.Interceptor)
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.SecurityInterceptor, false)
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.SecurityInterceptor)
> 2007-01-26 11:23:43,708 639353 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,708 639353 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,708 639353 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor, false)
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor)
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.InvokerInterceptor, false)
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.InvokerInterceptor)
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.id.GUID, false)
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.id.GUID)
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.id.UID, false)
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.id.UID)
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.id.VMID, false)
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.id.VMID)
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.platform.PID, false)
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.platform.PID)
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.InvocationContext, false)
> 2007-01-26 11:23:43,792 639437 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.InvocationContext)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.util.HashMap, false)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.InvocationKey, false)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.InvocationKey)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,794 639439 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,794 639439 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy, false)
> 2007-01-26 11:23:43,796 639441 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,796 639441 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy)
> 2007-01-26 11:23:43,796 639441 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,797 639442 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,802 639447 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.jrmp.server.JRMPInvoker_Stub, false)
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.jrmp.server.JRMPInvoker_Stub)
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,812 639457 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.lang.Number, false)
> 2007-01-26 11:23:43,831 639476 DEBUG [be.certipost.am.utils.jboss.Utils] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) DONE Flushing principal for user null for security domain CertiOne on server 10.100.204.101
> 2007-01-26 11:23:43,835 639480 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preRemoveVariable.studioErrorTracking
> 2007-01-26 11:23:43,835 639480 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.postRemoveVariable.studioErrorTracking
> 2007-01-26 11:23:43,835 639480 DEBUG [org.jboss.seam.interceptors.RemoveInterceptor] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Stateful component was removed: studioErrorTracking
> 2007-01-26 11:23:43,839 639484 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preRemoveVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,839 639484 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.postRemoveVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,840 639485 WARN [org.jboss.seam.contexts.Contexts] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Could not destroy component: studioErrorTracking
> javax.ejb.EJBAccessException: Authentication failure
> at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
> at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:71)
> 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.stateful.StatefulContainer.localInvoke(StatefulContainer.java:188)
> at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:98)
> at $Proxy350.stop(Unknown Source)
> at be.certipost.gui.studio.tracking.beans.ErrorTracking$$FastClassByCGLIB$$51bd700e.invoke()
> at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
> at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:73)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:55)
> at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:39)
> 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.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
> at org.jboss.seam.interceptors.ExceptionInterceptor.handleExceptions(ExceptionInterceptor.java:38)
> at sun.reflect.GeneratedMethodAccessor145.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
> at org.jboss.seam.interceptors.SynchronizationInterceptor.serialize(SynchronizationInterceptor.java:30)
> at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
> at org.jboss.seam.intercept.RootInterceptor.createSeamInvocationContext(RootInterceptor.java:144)
> at org.jboss.seam.intercept.RootInterceptor.invokeInContexts(RootInterceptor.java:129)
> at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:102)
> at org.jboss.seam.intercept.ClientSideInterceptor.interceptInvocation(ClientSideInterceptor.java:82)
> at org.jboss.seam.intercept.ClientSideInterceptor.intercept(ClientSideInterceptor.java:51)
> at org.jboss.seam.intercept.Proxy$$EnhancerByCGLIB$$4b2b9a98.stop()
> 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.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:102)
> at org.jboss.seam.Component.callComponentMethod(Component.java:1791)
> at org.jboss.seam.Component.callDestroyMethod(Component.java:1747)
> at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:189)
> at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:230)
> at org.jboss.seam.servlet.SeamListener.sessionDestroyed(SeamListener.java:45)
> at org.apache.catalina.session.StandardSession.expire(StandardSession.java:687)
> at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:579)
> at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:678)
> at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:663)
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1284)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1569)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1558)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.auth.login.LoginException: be.certipost.am.InvalidUsernameException: Invalid username: null
> at be.certipost.am.utils.loginmodule.AMBasedLoginModule.login(AMBasedLoginModule.java:146)
> at be.certipost.certione.loginmodule.CertioneAMBasedLoginModule.login(CertioneAMBasedLoginModule.java:56)
> 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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
> at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:601)
> at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535)
> at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
> at org.jboss.aspects.security.AuthenticationInterceptor.authenticate(AuthenticationInterceptor.java:121)
> at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:67)
> ... 61 more
> Caused by: be.certipost.am.InvalidUsernameException: Invalid username: null
> at be.certipost.am.bl.AuthenticationBLBean.authenticate(AuthenticationBLBean.java:54)
> at sun.reflect.GeneratedMethodAccessor410.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.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
> at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
> 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 $Proxy523.authenticate(Unknown Source)
> 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 be.certipost.am.utils.blfactory.AMBLFactory$AuthenticationBLProxyHandler.invoke(AMBLFactory.java:154)
> at $Proxy524.authenticate(Unknown Source)
> at be.certipost.am.utils.loginmodule.AMBasedLoginModule.loginWithPassword(AMBasedLoginModule.java:176)
> at be.certipost.am.utils.loginmodule.AMBasedLoginModule.login(AMBasedLoginModule.java:118)
> ... 77 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 lists.jboss.org  Wed Aug  8 08:44:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 08:44:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-137) problem configuriing
 exception class
Message-ID: <7080582.1186577089238.JavaMail.jira@cloud.prod.atl2.jboss.com>

problem configuriing exception class
------------------------------------

                 Key: GPD-137
                 URL: http://jira.jboss.com/jira/browse/GPD-137
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
            Reporter: Koen Aers
         Assigned To: Koen Aers
             Fix For: jBPM JPDL Designer 3.1.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 09:04:04 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 09:04:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-138) error dialogue appears
 on task panel of properties for task node
Message-ID: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>

error dialogue appears on task panel of properties for task node
----------------------------------------------------------------

                 Key: GPD-138
                 URL: http://jira.jboss.com/jira/browse/GPD-138
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: os x macbok pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Minor


Hi,

when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :

Reason:
0

'An error has occurred. See error log for more details.
0

On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 09:46:49 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 09:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
Message-ID: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>

CacheInvalidator.areInvalid doesn't lock partitions
---------------------------------------------------

                 Key: JBAS-4597
                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1


org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 10:02:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Wed, 8 Aug 2007 10:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1029) Can't use JMock
 to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31972842.1186581769535.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

John Doe resolved JBRULES-1029.
-------------------------------

    Fix Version/s:  4.0.0.GA
                       (was: 4.0.1)
       Resolution: Done

After I moved classes to package test.drools and changed rule as

package sample;

import test.drools.ResultsInterface;
import test.drools.ContentStorageInterface;
import test.drools.RuleHelper;

rule "Verify_1"
    when
	content : ContentStorageInterface()
	results : ResultsInterface( resultsCount > 0) 
	    from RuleHelper.search(content,"pattern","column")
    then
	System.out.println( results ); 
end

everything compiled and at least test was passed.

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For:  4.0.0.GA
>
>         Attachments: drools.zip
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 10:04:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Wed, 8 Aug 2007 10:04:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1029) Can't use JMock to
	mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25750642.1186581889377.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

John Doe closed JBRULES-1029.
-----------------------------


fixed in trunk?

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For:  4.0.0.GA
>
>         Attachments: drools.zip
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 10:26:49 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 10:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
In-Reply-To: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27661322.1186583209407.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Alexey Loubyansky updated JBAS-4597:
------------------------------------

    Fix Version/s: JBossAS-4.0.5.SP1 

> CacheInvalidator.areInvalid doesn't lock partitions
> ---------------------------------------------------
>
>                 Key: JBAS-4597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-3.2.8.SP1, JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.SP1 ,  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1
>
>
> org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 10:50:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 10:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1028) Lazy transaction
 enlistment is not working
Message-ID: <2588803.1186584602584.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lazy transaction enlistment is not working
------------------------------------------

                 Key: EJBTHREE-1028
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1028
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf
             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug  8 11:01:04 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 11:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-137) problem configuriing
 exception class
In-Reply-To: <7080582.1186577089238.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12020536.1186585264421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-137?page=all ]

Koen Aers updated GPD-137:
--------------------------

    Component/s: jpdl

> problem configuriing exception class
> ------------------------------------
>
>                 Key: GPD-137
>                 URL: http://jira.jboss.com/jira/browse/GPD-137
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 11:06:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 11:06:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-138) error dialogue appears
 on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2016898.1186585609565.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-138?page=all ]

Koen Aers closed GPD-138.
-------------------------

    Resolution: Cannot Reproduce Bug

I could not reproduce this on the current head. Can you verify if the problem also exists in today's release and reopen if necessary?

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 11:10:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 11:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20375432.1186585849352.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371499 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

hi, sorry today's release of what, the plugin or Eclipse ?

cheers

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 11:18:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 11:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9674334.1186586329380.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371501 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

of the plugin... it is the release candidate before the final that is supposed to be released next week.

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 11:34:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 11:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14052660.1186587289367.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371504 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

ah ok, I will check first thing tomorrow morning, just off to a meeting now till end of play today

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 12:47:49 2007
From: jira-events at lists.jboss.org (liz ch (JIRA))
Date: Wed, 8 Aug 2007 12:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1035) CLONE -deploy a
 process archive documentation incorrect
Message-ID: <4397147.1186591669572.JavaMail.jira@cloud.prod.atl2.jboss.com>

CLONE -deploy a process archive documentation incorrect
-------------------------------------------------------

                 Key: JBPM-1035
                 URL: http://jira.jboss.com/jira/browse/JBPM-1035
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Documentation
    Affects Versions: jBPM 3.0.2
            Reporter: liz ch
         Assigned To: Tom Baeyens


Under section 13.1.1 - Deploying a proceses archive:

The code sample for  target name="deploy.par" is incorrect:  The task definition rg.jbpm.jpdl.par.ProcessArchiveDeployerTask should be org.jbpm.ant.DeployParTask

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 13:13:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-675) Able to kill and
 suspend a process or token that has ended
Message-ID: <29988787.1186593182520.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-675?page=comments#action_12371509 ] 
            
Ronald van Kuijk commented on JBPM-675:
---------------------------------------

works on 3.2, should this still be fixed in 3.1? I assign it to 3.1.5, and see what happens

> Able to kill and suspend a process or token that has ended
> ----------------------------------------------------------
>
>                 Key: JBPM-675
>                 URL: http://jira.jboss.com/jira/browse/JBPM-675
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>         Environment: Mac OS X 10.4.6 Java 1.4.2_09
>            Reporter: michaelklem
>         Assigned To: Tom Baeyens
>            Priority: Trivial
>             Fix For: jBPM 3.1.5
>
>
> When a process instance or token has ended, I can still call the suspend, resume and kill APIs on that process instance or token without an exception being thrown. IMO an exception should be thrown to indicate that these APIs are used in an illegal 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 lists.jboss.org  Wed Aug  8 13:13:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-675) Able to kill and
 suspend a process or token that has ended
Message-ID: <7256345.1186593182719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-675?page=all ]

Ronald van Kuijk updated JBPM-675:
----------------------------------

        Fix Version/s: jBPM 3.1.5
    Affects Version/s:     (was: jBPM 3.1.1)

> Able to kill and suspend a process or token that has ended
> ----------------------------------------------------------
>
>                 Key: JBPM-675
>                 URL: http://jira.jboss.com/jira/browse/JBPM-675
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>         Environment: Mac OS X 10.4.6 Java 1.4.2_09
>            Reporter: michaelklem
>         Assigned To: Tom Baeyens
>            Priority: Trivial
>             Fix For: jBPM 3.1.5
>
>
> When a process instance or token has ended, I can still call the suspend, resume and kill APIs on that process instance or token without an exception being thrown. IMO an exception should be thrown to indicate that these APIs are used in an illegal 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 lists.jboss.org  Wed Aug  8 13:14:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-675) Able to kill and
 suspend a process or token that has ended
Message-ID: <19490451.1186593289663.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-675?page=all ]

Ronald van Kuijk updated JBPM-675:
----------------------------------

    Affects Version/s: jBPM 3.1.1

> Able to kill and suspend a process or token that has ended
> ----------------------------------------------------------
>
>                 Key: JBPM-675
>                 URL: http://jira.jboss.com/jira/browse/JBPM-675
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Mac OS X 10.4.6 Java 1.4.2_09
>            Reporter: michaelklem
>         Assigned To: Tom Baeyens
>            Priority: Trivial
>             Fix For: jBPM 3.1.5
>
>
> When a process instance or token has ended, I can still call the suspend, resume and kill APIs on that process instance or token without an exception being thrown. IMO an exception should be thrown to indicate that these APIs are used in an illegal 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 lists.jboss.org  Wed Aug  8 13:50:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 13:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-789) Release 2.2.1.SP1
Message-ID: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release 2.2.1.SP1
-----------------

                 Key: JBREM-789
                 URL: http://jira.jboss.com/jira/browse/JBREM-789
             Project: JBoss Remoting
          Issue Type: Release
      Security Level: Public (Everyone can see)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 13:50:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 13:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23574019.1186595449583.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-789:
----------------------------

        Fix Version/s: 2.2.1.SP1
    Affects Version/s: 2.2.1.SP1

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.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 lists.jboss.org  Wed Aug  8 13:52:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:52:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1035) CLONE -deploy a
 process archive documentation incorrect
In-Reply-To: <4397147.1186591669572.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26754020.1186595569459.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1035?page=all ]

Ronald van Kuijk closed JBPM-1035.
----------------------------------

    Resolution: Won't Fix

3.0.2 docs will not be updated anymore

> CLONE -deploy a process archive documentation incorrect
> -------------------------------------------------------
>
>                 Key: JBPM-1035
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1035
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: jBPM 3.0.2
>            Reporter: liz ch
>         Assigned To: Tom Baeyens
>
> Under section 13.1.1 - Deploying a proceses archive:
> The code sample for  target name="deploy.par" is incorrect:  The task definition rg.jbpm.jpdl.par.ProcessArchiveDeployerTask should be org.jbpm.ant.DeployParTask

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 13:59:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Wed, 8 Aug 2007 13:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-111) Add ability to
 forward and reverse
 map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11479079.1186595989420.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Matthew Sandoz reopened GPD-111:
--------------------------------

             
sorry to have to reopen this but there are several use cases and the one i overlooked yesterday isnt working. 

when i create a node from the palette, the createAdapterFromModel method of the XmlAdapterFactory is called. At the end of this, the factory calls createAdapterFromElementName. Unfortunately this doesnt allow the factory to create an adapter specific to the SemanticElement, but rather the node name. The node name is shared among many classes and so always returns the same adapter.

I was able to get around this as in my original code by adding the following into the createAdapterFromModel method:

		INodeNotifier element = (INodeNotifier)document.createElement(elementName);
		XmlAdapter result;
		try {
			result = (XmlAdapter) configurationElement.createExecutableExtension("adapterClass");
			result.setNode((Node)element);
			result.setFactory(this);
			return result;
		} catch (CoreException e) {
			Logger.logError("Unable to create XML Adapter for " + jpdlElement.getElementId(), e);
		}

right before the final return. 

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:12:16 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:12:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1024) Distributed
 queue stops working when node is killed
Message-ID: <3119231.1186596736249.JavaMail.jira@cloud.prod.atl2.jboss.com>

Distributed queue stops working when node is killed
---------------------------------------------------

                 Key: JBMESSAGING-1024
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1024
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


If start a test with 3 nodes, then kill one of them then the distributed queue doesn't work.

Try starting DistributedRequestResponseTest with 3 nodes then killing to replicate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:19:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1025) Add test in
 GroupManagementTest
Message-ID: <24748680.1186597189354.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add test in GroupManagementTest
-------------------------------

                 Key: JBMESSAGING-1025
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1025
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


.... that tests that failover map is created in vew order

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:19:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases, also DB2
Message-ID: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ensure successfull test run against all supported databases, also DB2
---------------------------------------------------------------------

                 Key: JBMESSAGING-1026
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:21:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1027) Client
	updating fails
Message-ID: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Client updating fails
---------------------

                 Key: JBMESSAGING-1027
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Client side node list updating currently only occurs if there is an active connection on the connection factory.

This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:23:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1028) Cleanup
 groupmember startup
Message-ID: <20025793.1186597429469.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cleanup groupmember startup
---------------------------

                 Key: JBMESSAGING-1028
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1028
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Cleanup the group member startup so we ensure that view change precedes state arrival precedes messages.

Add sanity checks to ensure this is the 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 lists.jboss.org  Wed Aug  8 14:25:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1029) Deadlock in
 messaging postoffice
Message-ID: <28783104.1186597549324.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock in messaging postoffice
--------------------------------

                 Key: JBMESSAGING-1029
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1029
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:27:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1030) Updated JBM
 to use new patched JBoss remoting jar
Message-ID: <11490984.1186597669494.JavaMail.jira@cloud.prod.atl2.jboss.com>

Updated JBM to use new patched JBoss remoting jar
-------------------------------------------------

                 Key: JBMESSAGING-1030
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1030
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Update JBM to use new patched jar which resolves all known remoting 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 lists.jboss.org  Wed Aug  8 14:27:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Wed, 8 Aug 2007 14:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11455958.1186597669669.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371517 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

i will attach a file with the changes as this solution doesnt seem to be perfect yet.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:31:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1031) Potential bug
 in cancelling delivery
Message-ID: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>

Potential bug in cancelling delivery
------------------------------------

                 Key: JBMESSAGING-1031
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:34:04 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:34:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1032) Problem with
 bridge when source is remote
Message-ID: <25187402.1186598044726.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem with bridge when source is remote
-----------------------------------------

                 Key: JBMESSAGING-1032
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1032
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Need to investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:37:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1033) Rationalise
 and speedup test suite
Message-ID: <9387617.1186598269311.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rationalise and speedup test suite
----------------------------------

                 Key: JBMESSAGING-1033
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1033
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


After migration to Hudson - the test takes far too long to run.

It needs to be speeded up if it is to be any use.

The clustering, bridge and thirdparty tests do not need to be run against all databases, only the invm and remote tests 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 lists.jboss.org  Wed Aug  8 14:39:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1034) Allow
 connection factories to be created programmatically
Message-ID: <9067157.1186598389285.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow connection factories to be created programmatically
---------------------------------------------------------

                 Key: JBMESSAGING-1034
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1034
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 1


We should allow connection factories to be created programmatically on the client side - this allows people to use JBM when they don't have JNDI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:42:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1035) Potential
	security issue
Message-ID: <6455963.1186598569318.JavaMail.jira@cloud.prod.atl2.jboss.com>

Potential security issue
------------------------

                 Key: JBMESSAGING-1035
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1035
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Need to investigate whether there is an issue here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:46:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1036) Consider
 createing JBossDestination interface
Message-ID: <10696945.1186598809453.JavaMail.jira@cloud.prod.atl2.jboss.com>

Consider createing JBossDestination interface
---------------------------------------------

                 Key: JBMESSAGING-1036
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1036
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


To solve forum 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 lists.jboss.org  Wed Aug  8 14:56:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1014) Look at
	JGroups anycast
In-Reply-To: <9508348.1184347872500.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31587419.1186599409354.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-1014:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Look at JGroups anycast
> -----------------------
>
>                 Key: JBMESSAGING-1014
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1014
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> To avoid issue with having to multicast even when there is only one subscriber

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 16:17:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Wed, 8 Aug 2007 16:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18175299.1186604269751.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371539 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Hi again

All the dependencies that I am supposed to have in the application at runtime I want to specify as dependencies.
Pleazze make no no hidden things here....

I know very little about the AOP, but if I am supposed to use i.e. the <concurrent> artifact I understand I have to add it and I want to do so. 

My claim goes on the artifacts that the plugin uses to run the plugin at compile time. These artifacts should NOT become part of the runtime.

If you make the plugin in a way that the plugin ends up managing runtime artifacts I think it is BAD. Then you will need to issue a new version of the plugin each time the AOP / Jboss-server changes anything.


> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 16:19:54 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Wed, 8 Aug 2007 16:19:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17825499.1186604394021.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371540 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

ok this appears to be working now - heres a patch from eclipse from the eclipse "Create Patch" - is that the best way to provide these? if not i can attach the entire file...

### Eclipse Workspace Patch 1.0
#P org.jbpm.gd.jpdl
Index: src/org/jbpm/gd/common/xml/XmlAdapterFactory.java
===================================================================
RCS file: /cvsroot/jbpm/jbpm.3/designer/jpdl/org.jbpm.gd.jpdl/src/org/jbpm/gd/common/xml/XmlAdapterFactory.java,v
retrieving revision 1.8
diff -u -r1.8 XmlAdapterFactory.java
--- src/org/jbpm/gd/common/xml/XmlAdapterFactory.java	7 Aug 2007 13:02:45 -0000	1.8
+++ src/org/jbpm/gd/common/xml/XmlAdapterFactory.java	8 Aug 2007 20:16:40 -0000
@@ -99,6 +99,17 @@
 					Logger.logError("Neither xmlElement nor nameProvider are present on mapping configuration element for " + jpdlElement.getElementId(), e);
 				}
 			}
+		} else {
+			try {
+				XmlAdapter adapter = (XmlAdapter) configurationElement.createExecutableExtension("adapterClass");
+				INodeNotifier element = (INodeNotifier)document.createElement(elementName);
+				element.addAdapter(adapter);
+				adapter.setNode((Node)element);
+				adapter.setFactory(this);
+				return adapter;
+			} catch (CoreException e) {
+				Logger.logError("Unable to create XML Adapter for " + jpdlElement.getElementId(), e);
+			}
 		}
 		return elementName == null ? null : createAdapterFromElementName(elementName);
 	}



> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 16:32:49 2007
From: jira-events at lists.jboss.org (Michael Newcomb (JIRA))
Date: Wed, 8 Aug 2007 16:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-571) all threads are daemon
Message-ID: <20660552.1186605169499.JavaMail.jira@cloud.prod.atl2.jboss.com>

all threads are daemon
----------------------

                 Key: JGRP-571
                 URL: http://jira.jboss.com/jira/browse/JGRP-571
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
            Reporter: Michael Newcomb
         Assigned To: Bela Ban


Create and join a channel, then LockSupport.park() in main.
Dump out all Threads (ctrl-break) and they are all daemon.

Thread Pool threads get marked daemon because they are created from the IO threads (which are daemon).

Recommend searching for setDaemon(true) and determining if all uses are correct.

Caused my program (which is event/message driven) to immediately exit.

"Incoming Thread,137.161.130.87:1956" daemon prio=10 tid=0x033ad400 nid=0x2378 waiting on condition [0x040cf000..0x040cfc94]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x24107308> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
	at java.lang.Thread.run(Thread.java:619)

"MERGE2.FindSubgroups thread (channel=iewtpt, local_addr=137.161.130.87:1956)" daemon prio=6 tid=0x033a9800 nid=0xe70 waiting on condition [0x0407f000..0x0407fd14]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at org.jgroups.util.Util.sleep(Util.java:851)
	at org.jgroups.protocols.MERGE2$FindSubgroups.run(MERGE2.java:265)
	at java.lang.Thread.run(Thread.java:619)

"OOB Thread,137.161.130.87:1956" daemon prio=10 tid=0x0337b400 nid=0x24bc waiting on condition [0x0411f000..0x0411fd94]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x241000f0> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
	at java.lang.Thread.run(Thread.java:619)

"ServerSocket acceptor thread (channel=iewtpt)" daemon prio=6 tid=0x033a8800 nid=0x1e38 runnable [0x0402f000..0x0402fb14]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
	- locked <0x24100258> (a java.net.SocksSocketImpl)
	at java.net.ServerSocket.implAccept(ServerSocket.java:450)
	at java.net.ServerSocket.accept(ServerSocket.java:421)
	at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:1073)
	at java.lang.Thread.run(Thread.java:619)

"UDP mcast receiver,137.161.130.87:1956" daemon prio=10 tid=0x0303ec00 nid=0x2170 runnable [0x03fdf000..0x03fdfc14]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
	- locked <0x24100458> (a java.net.DatagramPacket)
	- locked <0x24100478> (a java.net.MulticastSocket)
	at org.jgroups.protocols.UDP.run(UDP.java:247)
	at java.lang.Thread.run(Thread.java:619)

"UDP ucast receiver,137.161.130.87:1956" daemon prio=6 tid=0x02ff3000 nid=0x2734 runnable [0x03f8f000..0x03f8fb94]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
	- locked <0x241006c0> (a java.net.DatagramPacket)
	- locked <0x241006e0> (a java.net.DatagramSocket)
	at org.jgroups.protocols.UDP$UcastReceiver.run(UDP.java:916)
	at java.lang.Thread.run(Thread.java:619)

"main" prio=6 tid=0x001ca000 nid=0x208 waiting on condition [0x002af000..0x002afe54]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283)
	at HostNode.main(HostNode.java:607)
	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:17:49 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-272) allow xpath
 expression/query to create more than one occurrence of an element
In-Reply-To: <21460509.1185436907082.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6209133.1186607869788.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-272?page=comments#action_12371547 ] 
            
Alejandro Guizar commented on BPEL-272:
---------------------------------------

Thanks for the reference. However, as far as I can see, the extension function has no advantages over the "last plus one" predicate. Both compromise the portability of the process definition. 

On the other hand, the extension function has one clear disadvantage. Consider the signature:

addChildNode(Element e, Node childNode)

To implement it, the element e must be cloned, the childNode appended to the clone, and the whole thing copied to the destination. In consequence, the function above has time and space requirements proportional to the size of the array. The "last plus one" predicate, while somewhat dirty, has constant performance.

An alternate,cleaner approach is to leverage the <bpel2:extensionAssignOperation> construct. Apart from the standard <bpel2:copy> we could offer a <jbpm:append> operation to perform this exact manipulation without abusing XPath syntax or introducing a function of linear performance. 

Unfortunately there is no <extensionAssignOperation> construct in BPEL 1.1, which is what prevented me from proposing this approach in the first place. There is a workaround, though: <jbpm:append> elements can appear directly under the <bpel11:assign> element.

> allow xpath expression/query to create more than one occurrence of an element
> -----------------------------------------------------------------------------
>
>                 Key: BPEL-272
>                 URL: http://jira.jboss.com/jira/browse/BPEL-272
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The current XPath sublanguage implementation automatically creates nodes missing from location paths during assignment. This facility has a number of conceptual limitations. One of them is the inability to append a child element to an existing element if the latter already has a child element with the same name. There is no XPath syntax to express that a new element is required!
> It is tempting to think of a numeric XPath predicate as an array index, leading to the next snippet:
> <copy>
>  <from><literal>haha</literal></from>
>  <to variable='laughter' xmlns:ex='http://jbpm.org/bpel/examples'>
>   <query>ex:laugh[last() + 1]</query>
>  </to>
> </copy>
> However, such an interpretation of a predicate is wrong. Consider the following extract from XPath 1.0 specification on predicates:
> "A PredicateExpr is evaluated by evaluating the Expr and converting the result to a boolean. If the result is a number, the result will be converted to true if the number is equal to the context position and will be converted to false otherwise."
> The description of the last() function reads:
> "The last function returns a number equal to the context size from the expression evaluation context."
> Noticed the problem? The context position is never greater than the context size. Therefore the predicate [last() + 1] does not represent the position "one past the context size" but the boolean value false. Unfortunately, no other predicate seems appropriate. 
> PROPOSAL Introduce a minor deviation from the XPath 1.0 specification. Interpret the result of a numeric predicate that equals the context size plus one as a  request to create a new occurrence of the 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 lists.jboss.org  Wed Aug  8 17:19:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Aug 2007 17:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-571) all threads are daemon
In-Reply-To: <20660552.1186605169499.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <265215.1186607989414.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-571:
--------------------------

    Fix Version/s: 2.6

> all threads are daemon
> ----------------------
>
>                 Key: JGRP-571
>                 URL: http://jira.jboss.com/jira/browse/JGRP-571
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Michael Newcomb
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Create and join a channel, then LockSupport.park() in main.
> Dump out all Threads (ctrl-break) and they are all daemon.
> Thread Pool threads get marked daemon because they are created from the IO threads (which are daemon).
> Recommend searching for setDaemon(true) and determining if all uses are correct.
> Caused my program (which is event/message driven) to immediately exit.
> "Incoming Thread,137.161.130.87:1956" daemon prio=10 tid=0x033ad400 nid=0x2378 waiting on condition [0x040cf000..0x040cfc94]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x24107308> (a java.util.concurrent.SynchronousQueue$TransferStack)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
> 	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
> 	at java.lang.Thread.run(Thread.java:619)
> "MERGE2.FindSubgroups thread (channel=iewtpt, local_addr=137.161.130.87:1956)" daemon prio=6 tid=0x033a9800 nid=0xe70 waiting on condition [0x0407f000..0x0407fd14]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
> 	at java.lang.Thread.sleep(Native Method)
> 	at org.jgroups.util.Util.sleep(Util.java:851)
> 	at org.jgroups.protocols.MERGE2$FindSubgroups.run(MERGE2.java:265)
> 	at java.lang.Thread.run(Thread.java:619)
> "OOB Thread,137.161.130.87:1956" daemon prio=10 tid=0x0337b400 nid=0x24bc waiting on condition [0x0411f000..0x0411fd94]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x241000f0> (a java.util.concurrent.SynchronousQueue$TransferStack)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
> 	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
> 	at java.lang.Thread.run(Thread.java:619)
> "ServerSocket acceptor thread (channel=iewtpt)" daemon prio=6 tid=0x033a8800 nid=0x1e38 runnable [0x0402f000..0x0402fb14]
>    java.lang.Thread.State: RUNNABLE
> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
> 	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
> 	- locked <0x24100258> (a java.net.SocksSocketImpl)
> 	at java.net.ServerSocket.implAccept(ServerSocket.java:450)
> 	at java.net.ServerSocket.accept(ServerSocket.java:421)
> 	at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:1073)
> 	at java.lang.Thread.run(Thread.java:619)
> "UDP mcast receiver,137.161.130.87:1956" daemon prio=10 tid=0x0303ec00 nid=0x2170 runnable [0x03fdf000..0x03fdfc14]
>    java.lang.Thread.State: RUNNABLE
> 	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> 	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
> 	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
> 	- locked <0x24100458> (a java.net.DatagramPacket)
> 	- locked <0x24100478> (a java.net.MulticastSocket)
> 	at org.jgroups.protocols.UDP.run(UDP.java:247)
> 	at java.lang.Thread.run(Thread.java:619)
> "UDP ucast receiver,137.161.130.87:1956" daemon prio=6 tid=0x02ff3000 nid=0x2734 runnable [0x03f8f000..0x03f8fb94]
>    java.lang.Thread.State: RUNNABLE
> 	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> 	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
> 	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
> 	- locked <0x241006c0> (a java.net.DatagramPacket)
> 	- locked <0x241006e0> (a java.net.DatagramSocket)
> 	at org.jgroups.protocols.UDP$UcastReceiver.run(UDP.java:916)
> 	at java.lang.Thread.run(Thread.java:619)
> "main" prio=6 tid=0x001ca000 nid=0x208 waiting on condition [0x002af000..0x002afe54]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283)
> 	at HostNode.main(HostNode.java:607)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:19:49 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-272) allow xpath
 expression/query to create more than one occurrence of an element
In-Reply-To: <21460509.1185436907082.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18633525.1186607989574.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-272?page=comments#action_12371548 ] 
            
Alejandro Guizar commented on BPEL-272:
---------------------------------------

Extra note: Oracle has deprecated the addChildNode() function and is also going for the extension operation approach:

http://forums.oracle.com/forums/thread.jspa?threadID=305968

"
Please don't use the addChildNode() function, this function is going to deprecated, instead use the new bpel extension insert/append (bpelx:append):
Syntax:
<bpel:assign>
<bpelx:append>
<bpelx:from ... />
<bpelx:to ... />
</bpelx:append>
</bpel:assign>
"

> allow xpath expression/query to create more than one occurrence of an element
> -----------------------------------------------------------------------------
>
>                 Key: BPEL-272
>                 URL: http://jira.jboss.com/jira/browse/BPEL-272
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The current XPath sublanguage implementation automatically creates nodes missing from location paths during assignment. This facility has a number of conceptual limitations. One of them is the inability to append a child element to an existing element if the latter already has a child element with the same name. There is no XPath syntax to express that a new element is required!
> It is tempting to think of a numeric XPath predicate as an array index, leading to the next snippet:
> <copy>
>  <from><literal>haha</literal></from>
>  <to variable='laughter' xmlns:ex='http://jbpm.org/bpel/examples'>
>   <query>ex:laugh[last() + 1]</query>
>  </to>
> </copy>
> However, such an interpretation of a predicate is wrong. Consider the following extract from XPath 1.0 specification on predicates:
> "A PredicateExpr is evaluated by evaluating the Expr and converting the result to a boolean. If the result is a number, the result will be converted to true if the number is equal to the context position and will be converted to false otherwise."
> The description of the last() function reads:
> "The last function returns a number equal to the context size from the expression evaluation context."
> Noticed the problem? The context position is never greater than the context size. Therefore the predicate [last() + 1] does not represent the position "one past the context size" but the boolean value false. Unfortunately, no other predicate seems appropriate. 
> PROPOSAL Introduce a minor deviation from the XPath 1.0 specification. Interpret the result of a numeric predicate that equals the context size plus one as a  request to create a new occurrence of the 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 lists.jboss.org  Wed Aug  8 17:48:02 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 17:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
In-Reply-To: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30839466.1186609682276.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Alexey Loubyansky resolved JBAS-4597.
-------------------------------------

    Resolution: Done

Fixed.

> CacheInvalidator.areInvalid doesn't lock partitions
> ---------------------------------------------------
>
>                 Key: JBAS-4597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1, JBossAS-4.0.5.SP1 
>
>
> org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 17:48:02 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 17:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
In-Reply-To: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3443111.1186609682448.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Alexey Loubyansky closed JBAS-4597.
-----------------------------------


> CacheInvalidator.areInvalid doesn't lock partitions
> ---------------------------------------------------
>
>                 Key: JBAS-4597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1, JBossAS-4.0.5.SP1 
>
>
> org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 17:49:49 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-260) Flow activity might
 not reactivate parent token in race condition
In-Reply-To: <8655137.1183310457582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30673641.1186609789303.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-260?page=all ]

Alejandro Guizar resolved BPEL-260.
-----------------------------------

    Resolution: Done

> Flow activity might not reactivate parent token in race condition
> -----------------------------------------------------------------
>
>                 Key: BPEL-260
>                 URL: http://jira.jboss.com/jira/browse/BPEL-260
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> The flow activity suffers from the same problem as the join node in jPDL. When child tokens complete the nested activities concurrently, it is possible that all of them determine that the parent token must not be reactivated yet, leading to deadlock. The cause of this behavior is transaction isolation.
> To prevent this problem, the code to leave the flow must acquire exclusive access to the state of the concurrent tokens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:18 2007
From: jira-events at lists.jboss.org (Jerry Gauthier (JIRA))
Date: Wed, 8 Aug 2007 17:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3532) Inject DRM and DS
 into ClusterPartition
In-Reply-To: <5088873.1155941679968.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19444178.1186609938304.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3532?page=comments#action_12371552 ] 
            
Jerry Gauthier commented on JBAS-3532:
--------------------------------------

Modified implementation so that DRM is now injected into ClusterPartition and vice-versa.  This is different than the DistributedState implementation where DistributedState is injected into ClusterPartitionConfig which is then passed into ClusterPartition in its constructor.

I was initially unable to resolve circular dependencies between ClusterPartition and DRM when I tried injecting DRM into ClusterPartitionConfig so the newimplementation injects DRM into ClusterPartition itself.  I've left this issue open as I intend to revisit the use of DRM with ClusterPartitionConfig.

> Inject DRM and DS into ClusterPartition
> ---------------------------------------
>
>                 Key: JBAS-3532
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3532
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Jerry Gauthier
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> DRM and DS are now independent services.  Inject them into ClusterPartiton so they can be exposed via HAPartition.
> ClusterPartition in create or start must confirm that the injected DRM and DS are using the same JChannelFactory and stack that it is.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-151) export the reference
 of the published endpoint
Message-ID: <25007765.1186609939421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-151?page=all ]

Alejandro Guizar resolved BPEL-151.
-----------------------------------

    Resolution: Done

> 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
>             Fix For: jBPM BPEL 1.1 GA
>
>
> 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 lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-261) use varbinary
 instead of varchar as data type to store dom elements
In-Reply-To: <19942189.1183411377618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14279188.1186609939574.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-261?page=all ]

Alejandro Guizar resolved BPEL-261.
-----------------------------------

    Resolution: Done

> use varbinary instead of varchar as data type to store dom elements
> -------------------------------------------------------------------
>
>                 Key: BPEL-261
>                 URL: http://jira.jboss.com/jira/browse/BPEL-261
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> The documentation for javax.xml.transform.stream.StreamResult {http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/stream/StreamResult.html} reads:
> Normally, a stream should be used rather than a [writer], so that the transformer may use instructions contained in the transformation instructions to control the encoding.
> It turns out byte streams are preferred over character streams. In consequence, the data type used to store dom elements in the database should be varbinary rather than varchar. Plus, the byte stream output lends itself better to compression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-262) redeliver messages
 whose handling fails due to stale state exceptions
In-Reply-To: <24810637.1183417437672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <184088.1186609939767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-262?page=all ]

Alejandro Guizar resolved BPEL-262.
-----------------------------------

    Resolution: Done

> redeliver messages whose handling fails due to stale state exceptions
> ---------------------------------------------------------------------
>
>                 Key: BPEL-262
>                 URL: http://jira.jboss.com/jira/browse/BPEL-262
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM. Upon message reception, a new transaction begins and process execution proceeds. It is possible that other portions of the process execute in separate transactions. Concurrent process execution may cause stale state or lock acquisition exceptions to be thrown in one or more transactions.
> PROPOSAL. Detect stale state and lock acquisition exceptions in JMS message listeners. Do not acknowledge the affected message. Recover the JMS 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 lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-263) incorporate
 enterprise support features from jpdl
In-Reply-To: <22029896.1183627611000.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11001705.1186609939902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-263?page=all ]

Alejandro Guizar resolved BPEL-263.
-----------------------------------

    Resolution: Done

> incorporate enterprise support features from jpdl
> -------------------------------------------------
>
>                 Key: BPEL-263
>                 URL: http://jira.jboss.com/jira/browse/BPEL-263
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> jBPM jPDL 3.2 introduced a number of enterprise features, including a scheduler service based on the EJB timer service and a persistence service configured for JTA.   Due to its reliance on J2EE Web Services, jBPM BPEL always runs in an enterprise environment. Incorporating the enterprise features available in jPDL is a clear step towards taking better advantage of the functionality offered by the application 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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-264) NPE when dead-path
 elimination reaches a flow with local links
In-Reply-To: <4995666.1184838827080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26508613.1186609940042.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Alejandro Guizar resolved BPEL-264.
-----------------------------------

    Resolution: Done

> NPE when dead-path elimination reaches a flow with local links
> --------------------------------------------------------------
>
>                 Key: BPEL-264
>                 URL: http://jira.jboss.com/jira/browse/BPEL-264
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-265) structured
 activities tell they
 are initial even if they are the targets of links
In-Reply-To: <27245367.1184840027145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12884001.1186609940202.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-265?page=all ]

Alejandro Guizar resolved BPEL-265.
-----------------------------------

    Resolution: Done

> structured activities tell they are initial even if they are the targets of links
> ---------------------------------------------------------------------------------
>
>                 Key: BPEL-265
>                 URL: http://jira.jboss.com/jira/browse/BPEL-265
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-266) incorporate
 targetNamespace in process definition versioning
In-Reply-To: <9147436.1184968007265.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11407405.1186609940344.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-266?page=all ]

Alejandro Guizar resolved BPEL-266.
-----------------------------------

    Resolution: Done

> incorporate targetNamespace in process definition versioning
> ------------------------------------------------------------
>
>                 Key: BPEL-266
>                 URL: http://jira.jboss.com/jira/browse/BPEL-266
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM So far, process definition versioning has ignored the targetNamespace attribute. Unlike jPDL, BPEL uses qualified names for processes. The targetNamespace attribute is mandatory and must be taken into account when determining the latest process definition for a given name.
> SOLUTION Extend the existing GraphSession with process deployment/query methods that explicitly take the targetNamespace as a parameter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-267) NPE extracting
 content from soap envelope containing default namespace declarations
In-Reply-To: <2721852.1184969687093.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2823228.1186609940484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-267?page=all ]

Alejandro Guizar resolved BPEL-267.
-----------------------------------

    Resolution: Done

> NPE extracting content from soap envelope containing default namespace declarations
> -----------------------------------------------------------------------------------
>
>                 Key: BPEL-267
>                 URL: http://jira.jboss.com/jira/browse/BPEL-267
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-269) enhance assignment
 logging capabilities
In-Reply-To: <33342002.1185080388867.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13958071.1186609940624.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-269?page=all ]

Alejandro Guizar resolved BPEL-269.
-----------------------------------

    Resolution: Done

> enhance assignment logging capabilities
> ---------------------------------------
>
>                 Key: BPEL-269
>                 URL: http://jira.jboss.com/jira/browse/BPEL-269
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM When a bpel:uninitializedVariable fault is thrown, it does not log which variable was uninitialized. Further, logging of extraction and assignment of values is generally scarce. 
> SOLUTION Log the uninitialized variables. Add extraction/assignment logs to all from/to variants.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-270) Add support for
 extensionAssignOperation
In-Reply-To: <13309174.1185081467208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22902965.1186609940772.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-270?page=all ]

Alejandro Guizar resolved BPEL-270.
-----------------------------------

    Resolution: Done

> Add support for extensionAssignOperation
> ----------------------------------------
>
>                 Key: BPEL-270
>                 URL: http://jira.jboss.com/jira/browse/BPEL-270
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM In BPEL 2, <extensibleAssignOperation> elements can appear as children of the <assign> activity, alongside standard <copy> elements. Our current design does not permit the addition of custom assign operations.
> SOLUTION Generalize Copy to AssignOperation. Introduce a parsing framework that permits the creation of custom 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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-271) NPE when a start IMA
 references a nonglobal variable
In-Reply-To: <20192567.1185408767068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <163282.1186609940938.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-271?page=all ]

Alejandro Guizar resolved BPEL-271.
-----------------------------------

    Resolution: Done

> NPE when a start IMA references a nonglobal variable
> ----------------------------------------------------
>
>                 Key: BPEL-271
>                 URL: http://jira.jboss.com/jira/browse/BPEL-271
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> A start IMA (inbound message activity) can legally occur inside a scope and variables local to that scope. The revised ATM example illustrates this scenario. When jBPM BPEL delivers a message to the aforementioned IMA, it causes a NPE because it initializes global variables only.
> This problem affects references to non-global partner links and correlation sets 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 lists.jboss.org  Wed Aug  8 17:52:21 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-273) provide a
 declarative way to
 install new evaluator factories in the sublanguage framework
In-Reply-To: <14864822.1185917029305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29437658.1186609941098.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-273?page=all ]

Alejandro Guizar resolved BPEL-273.
-----------------------------------

    Resolution: Done

> provide a declarative way to install new evaluator factories in the sublanguage framework
> -----------------------------------------------------------------------------------------
>
>                 Key: BPEL-273
>                 URL: http://jira.jboss.com/jira/browse/BPEL-273
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The sublanguage framework is extensible; however, it only provides programmatic means to register evaluator factories for new languages.
> PROPOSAL Involves two actions:
> 1. Apply the resource-based declarative pattern currently employed in activity readers, catalog readers and endpoint reference factories to evaluator factories. 
> 2. Remove programmatic registration as well. It would allow the addition of new languages at runtime, which is untested and not currently 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 lists.jboss.org  Wed Aug  8 17:52:21 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-274) wsdl service
 generator: eliminate reliance on transitive imports
In-Reply-To: <19592587.1186087614143.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1165144.1186609941245.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-274?page=all ]

Alejandro Guizar resolved BPEL-274.
-----------------------------------

    Resolution: Done

> wsdl service generator: eliminate reliance on transitive imports
> ----------------------------------------------------------------
>
>                 Key: BPEL-274
>                 URL: http://jira.jboss.com/jira/browse/BPEL-274
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM Consider the following network of WSDL documents.
> <definitions name="d1" targetNamespace="ns1">
>  <import namespace="ns2" location="d2" />
>  <binding name="b" type="ns3:pt" />
> </definitions>
> <definitions name="d2" targetNamespace="ns2">
>  <import namespace="ns3" location="d3" />
>  <partnerLinkType name="plt">
>   <role portType="ns3:pt" />
>  </partnerLinkType>
> </definitions>
> <definitions name="d3" targetNamespace="ns3">
>  <portType name="pt" />
> </definitions>
> ns2:plt is able to resolve the reference tons3:pt, but ns1:b is not. The import element in d1 is not scanned because the binding refers to a port type in namespace ns3 and the import namespace URI is ns2. 
> jBPM BPEL is able to resolve such transitive references, but products like the Eclipse BPEL designer and JBossWS are not. 
> PROPOSAL While generating d1, create a direct import for d3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:21 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-175) reintroduce
 assignment to/from variable/part/query
Message-ID: <28744498.1186609941398.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-175?page=all ]

Alejandro Guizar resolved BPEL-175.
-----------------------------------

    Fix Version/s: jBPM BPEL 1.1 GA
                       (was: jBPM BPEL 1.1 beta 1)
       Resolution: Done

AssignReader now parses the BPEL 2 syntax.

> reintroduce assignment to/from variable/part/query
> --------------------------------------------------
>
>                 Key: BPEL-175
>                 URL: http://jira.jboss.com/jira/browse/BPEL-175
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>         Environment: dom, trax
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> Item 103 of the BPEL issues list (http://www.choreology.com/external/WS_BPEL_issues_list.html) proposed a new syntax to access process variables within XPath expressions. The original proposal eliminated the variable/part/query variant of from-spec and to-spec, so it was removed from the product.
> After quite some discussion this variant remained valid. Therefore, the variant must be reintroduced. In fact this is a positive thing because it simplifies upgrading documents written against version 1.1 to version 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 lists.jboss.org  Wed Aug  8 18:07:52 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Wed, 8 Aug 2007 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13798863.1186610872068.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12371556 ] 
            
Imran Naqvi commented on GPD-78:
--------------------------------

I just tested with the new code and I'm afraid the problem still exists. GenericElements (formerly ConfigInfoElements) are not added to an Action. The fix for this is commented out in ActionDomAdapter.initialize()
The following lines of code in that method are commented out:
//			GenericElement[] genericElements = action.getGenericElements();
//			for (int i = 0; i < genericElements.length; i++) {
//				addElement(genericElements[i]);
//			}

If we uncomment this it should work. We need similar code in GenericElementXmlAdapter.initialize()
A sample process definition to reproduce this problem is:
<?xml version="1.0"?> 

<process-definition name="Movie" version="11"> 
<start-state name="Start"> 
<transition to="Get MPEG Properties" /> 
</start-state> 
<node name="Get MPEG Properties"> 
<action class="SomeActionHandler"><send>010901</send> 
<keys> 
<entry> 
                                            <key>VarName</key> 
                                            <value>1122</value> 
                                </entry> 
</keys> 
<receive> 
<element>030101</element> 
<element>030102</element> 
</receive> 
</action> 
<transition to="End"/> </node> 
<end-state name="End" /> 

The GenericElements in the Action in the above process definition never get added.

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  8 18:09:53 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Wed, 8 Aug 2007 18:09:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7536614.1186610993883.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12371557 ] 
            
Imran Naqvi commented on GPD-78:
--------------------------------

btw tried reopening the issue myself but I dont think I have permissions for it.

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  8 18:32:49 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 8 Aug 2007 18:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7463384.1186612369477.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371558 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

the only new artifact in the pom is jboss-common. concurrent was added atm, but it will be removed with a newer version of jboss-aop. i believe that including jboss-common will not "tie you in" in any way, but its needed to use aopc. i dont have very strong feelings about this, but atm i feel that this would make it easier for the end user. please prove me wrong :)

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 19:06:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 19:06:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-992) Give wiki pages
	a facelift
In-Reply-To: <4544515.1181946808835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30696988.1186614409988.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-992.
-------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)
       Resolution: Done

> Give wiki pages a facelift
> --------------------------
>
>                 Key: JBMESSAGING-992
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-992
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: Unscheduled
>
>
> The current wiki pages - both user and development contain outdated information.
> We should update info, and add new content as 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 lists.jboss.org  Wed Aug  8 20:17:49 2007
From: jira-events at lists.jboss.org (Jeff Wang (JIRA))
Date: Wed, 8 Aug 2007 20:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-139) Cannot add tasks to
	the task node
Message-ID: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot add tasks to the task node
---------------------------------

                 Key: GPD-139
                 URL: http://jira.jboss.com/jira/browse/GPD-139
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
            Reporter: Jeff Wang
         Assigned To: Koen Aers


I am unable to add new tasks in the task node. When I go to the
tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:48:03 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1059) Online typos in
	Section 1
In-Reply-To: <15111425.1186340029389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9782517.1186620483846.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1059:
----------------------------------

    Fix Version/s: 4.0.1

> Online typos in Section 1
> -------------------------
>
>                 Key: JBRULES-1059
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1059
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: n/a  - concerns documentation availble for viewing over internet
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> miscellaneous typos
> http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/index.html
> Section 1.1
> modiied ? modified
> Drools will adding ? Drools will be adding
> Section 1.2.1
> explination ? explanation
> layed ? laid
> espically ? especially
> knowlegde ? knowledge
> Section 1.2.4
> preceeding ? preceding
> its ? it's
> Section 1.3.1
> shortley ? shortly
> Section 1.3.2
> conjuntive ? conjunctive
> disjuntive ? disjunctive
> Section 1.6.1
> grammer ? grammar
> deployeable ? deployable
> PackagBuilder ? PackageBuilder
> Section 1.6.4.6
> In the shaded box, should 'new List' simply be 'List' ?
> Section 1.6.5
> legible ? eligible
> section 1.6.6.1
> managable ? manageable
> section 1.6.7
> AgendEventListener ? AgendaEventListener

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:49:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4429942.1186620589853.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1027:
----------------------------------

    Fix Version/s: 4.0.1

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:49:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:49:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12277935.1186620590301.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1056:
----------------------------------

    Fix Version/s: 4.0.1

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Wed Aug  8 20:49:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:49:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
In-Reply-To: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27136666.1186620590553.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1058:
----------------------------------

    Fix Version/s: 4.0.1

> nested accessors with Sets - "not contains" is not a valid operator for MVEL
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-1058
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark McNally
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Following does not work:
> 		rule StateMatch
> 			when
> 			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
> 			then 	
> 				retract( $ca );
> 		end
> 		
> 		
> 		public class CandidateAssociation {
> 			private PatientDetails patientDetails;
> 			private NurseDetails   nurseDetails;
> 			private int overlapHours;
> 		
> 			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
> 				super();
> 				this.patientDetails = patientDetails;
> 				this.nurseDetails = nurseDetails;
> 				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
> 			}
> 		    [...]
> 		}
> 		
> 		public class NurseDetails {
> 			private Set stateLicensures = new HashSet();
> 			[...]
> 		}
> 		public class PatientDetails {
> 			private String state;
> 			[...]
> 		}
> Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 
> Also Noticed that the following workaround did not work:
> 		rule State
> 		    dialect "mvel"
> 			when
> 		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
> 			then 	
> 		  	    retract( $ca );
> 		end
> 		
> 		This produced this Exception:
> 		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
> 	        at org.drools.rule.Package.checkValidity(Package.java:408)
> 	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	        at [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:59:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1067) Allow RuleAgent
 to take a RuleBaseConfiguration to configure the RuleBase it creates
In-Reply-To: <28877644.1186573549478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13369884.1186621189582.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1067:
----------------------------------

    Fix Version/s: 4.0.1

> Allow RuleAgent to take a RuleBaseConfiguration to configure the RuleBase it creates
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1067
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1067
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Extend the API to allow a RuleAgent to use a  RuleBaseConfiguration object to configure the RuleBase it creates. For example, this will allow a user to specfiy options like Sequental mode etc when creating a RuleBase using a RuleAgent.
> I know that you can set RuleBase options for all RuleBases by setting the appropriate System properties when calling the java VM, but it would be nice to be able to set these individually via the API for each RuleBase created using a RuleAgent. I guess this could be done fairly easily by adding an extra constructor(s) to RuleAgent that takes a RuleBaseConfiguration object -- rbConfig, say -- and in RuleAgent when it creates a new RuleBase instead of just using RulebaseFactory.newRuleBase() use RulebaseFactory.newRuleBase(rbConfig) 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 lists.jboss.org  Wed Aug  8 20:59:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1061) jsr94 constants
 wrong package
 builder config constant, same name as rulebase config constant
In-Reply-To: <28549329.1186406629349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13161338.1186621189971.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1061:
----------------------------------

    Fix Version/s: 4.0.1

> jsr94 constants wrong package builder config constant, same name as rulebase config constant
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1061
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1061
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSR94
>    Affects Versions:  4.0.0.GA
>            Reporter: Juergen none
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> org.drools.jsr94.rules.Constants, line 49f:
>     /** <code>RuleExecutionSet</code> rulebase config constant. */
>     public static final String RES_RULEBASE_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";
>     
>     /** <code>RuleExecutionSet</code> package builder config constant. */
>     public static final String RES_PACKAGEBUILDER_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";    
> Packagebuilder config constant is same as rulebase config constant. yields classcast exception if a rulebase config is set:
> Caused by: java.lang.ClassCastException: org.drools.RuleBaseConfiguration
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:124)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:59:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:59:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1064) "->" notation
 for predicates missing in documentation
In-Reply-To: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21771001.1186621190250.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Any feedback or documentation changes recommendations for this?

> "->" notation for predicates missing in documentation
> -----------------------------------------------------
>
>                 Key: JBRULES-1064
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>            Priority: Minor
>
> the notation "->" for adressing complex terms is missing from 4.0.0 documentation.
> It has been "return value operator" in 3.0.6:
> <quoted from 3.0.6>
> Example 3.13. Return Value operator
> Person( girlAge : age, sex = "F" )
> Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
> </quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 21:54:05 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 21:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1067) Allow RuleAgent to
 take a RuleBaseConfiguration to configure the RuleBase it creates
In-Reply-To: <28877644.1186573549478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12058289.1186624445156.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1067.
---------------------------------

    Resolution: Done

> Allow RuleAgent to take a RuleBaseConfiguration to configure the RuleBase it creates
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1067
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1067
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Extend the API to allow a RuleAgent to use a  RuleBaseConfiguration object to configure the RuleBase it creates. For example, this will allow a user to specfiy options like Sequental mode etc when creating a RuleBase using a RuleAgent.
> I know that you can set RuleBase options for all RuleBases by setting the appropriate System properties when calling the java VM, but it would be nice to be able to set these individually via the API for each RuleBase created using a RuleAgent. I guess this could be done fairly easily by adding an extra constructor(s) to RuleAgent that takes a RuleBaseConfiguration object -- rbConfig, say -- and in RuleAgent when it creates a new RuleBase instead of just using RulebaseFactory.newRuleBase() use RulebaseFactory.newRuleBase(rbConfig) 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 lists.jboss.org  Wed Aug  8 23:03:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1061) jsr94 constants
 wrong package
 builder config constant, same name as rulebase config constant
In-Reply-To: <28549329.1186406629349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31514478.1186628629386.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1061.
---------------------------------

    Resolution: Done

> jsr94 constants wrong package builder config constant, same name as rulebase config constant
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1061
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1061
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSR94
>    Affects Versions:  4.0.0.GA
>            Reporter: Juergen none
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> org.drools.jsr94.rules.Constants, line 49f:
>     /** <code>RuleExecutionSet</code> rulebase config constant. */
>     public static final String RES_RULEBASE_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";
>     
>     /** <code>RuleExecutionSet</code> package builder config constant. */
>     public static final String RES_PACKAGEBUILDER_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";    
> Packagebuilder config constant is same as rulebase config constant. yields classcast exception if a rulebase config is set:
> Caused by: java.lang.ClassCastException: org.drools.RuleBaseConfiguration
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:124)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:05:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4258490.1186628749342.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

It should work we have the following unit test, which passes:
rule "test auto bindings 1"
when
	$p : Person();
	$c : Cheese( type == $p.likes, price == $c.price  )
then
    results.add( $p );
end

If you are sure this is a bug, you'll need to upload a self contained example that shows this regression.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Mark Proctor
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug  8 23:11:21 2007
From: jira-events at lists.jboss.org (Justin Zhou (JIRA))
Date: Wed, 8 Aug 2007 23:11:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-153) EJB timer
 clustering and failover support
In-Reply-To: <28686742.1163405681641.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31654626.1186629081798.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-153?page=comments#action_12371566 ] 
            
Justin Zhou commented on JBCLUSTER-153:
---------------------------------------

I am using jbpm ejb timer task executors. It will be nice the failover can work. 

> EJB timer clustering and failover support
> -----------------------------------------
>
>                 Key: JBCLUSTER-153
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-153
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>
> Support for clustered EJB timer service providing failover

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:17:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11846750.1186629469477.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I've tired this with the latest mvel and cannot reproduce the error.

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:33:00 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28335906.1186630380355.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1027.
---------------------------------

    Resolution: Cannot Reproduce Bug

This does not fail with trunk, unit test was added anyway.

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:38:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 23:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
Message-ID: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE in BisocketClientInvoker$PingTimerTask
------------------------------------------

                 Key: JBREM-790
                 URL: http://jira.jboss.com/jira/browse/JBREM-790
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
            Priority: Minor
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Wed Aug  8 23:44:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 23:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7392074.1186631041088.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fix applied to remoting_2_2_0_GA branch.

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Wed Aug  8 23:44:02 2007
From: jira-events at lists.jboss.org (Justin Zhou (JIRA))
Date: Wed, 8 Aug 2007 23:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-983) concurrent process
 execution fails
In-Reply-To: <30055235.1181555411656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11347051.1186631042180.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-983?page=comments#action_12371570 ] 
            
Justin Zhou commented on JBPM-983:
----------------------------------

I am using oracle 10g. If set treecache isolation to serializable, fork/join works for me, but not other levels. The problem is the treecache locking, looks like every transaction will lock the whole cache tree from root, under heavy load, lock timeout can happen. Is there anyway we can do lock a little smarter?

Will setting the datasource isolation level to serializable help? Unfortunately, I can not do it with oracle XA datasource.

So my question is that is this a bug or just a database isolation level issue?


> concurrent process execution fails
> ----------------------------------
>
>                 Key: JBPM-983
>                 URL: http://jira.jboss.com/jira/browse/JBPM-983
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: Hypersonic in-memory database, JobExecutor configured with 5 threads
>            Reporter: Alexander Schlett
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM 3.3
>
>         Attachments: SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java
>
>
> concurrent execution of async nodes with multiple JobExecutor threads fails. the effect is:
> 1) job sync within JobExecutor fails due to org.hibernate.StaleObjectStateException
> 2) process gets stuck in join node and never ends
> junit test for this is attached, it's a simple process with just a fork and a join and some scripts inbetween.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:49:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10658573.1186631389420.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I just ran this and got:
[ObjectInserted: handle=[fid:1260:1260:a Garbage { someNumber= 310, id= C }]; object=a Garbage { someNumber= 310, id= C }]
java.lang.OutOfMemoryError


Which means its running out of memory, just give your JVM session access to more memory.

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Wed Aug  8 23:53:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13289089.1186631629399.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

notice you have a nested loop:
            for (int i = 1; i <= 3; i++) {
                for (int j = 1; j <= 475; j++) {
so thats actually 1425 facts its attempting to insert.

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Thu Aug  9 02:13:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 9 Aug 2007 02:13:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10842486.1186640029470.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371574 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

I have now done some changes in the POM 
1) I add trove to the client pom
2) I removed dependency of the plugin
THIS WORKS !!!!!!!!!! --> I do not get maven artifacts in the final product !!!!! GOOD!!!!

BUT still I'm a little worried. I cannot write <scope>provided</scope> to any of the artifacts below....
To my understanding of maven I should be able to do that....

In the compiler plugin it is possible to write provided.
I think we should see how that plugin works !!!!!!
Or we should ask for help at maven.org??
It is still the MOJO statement cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
that worries me.
I have tried to use project.getCompileClasspathElements() but with the very same result..... 


    <dependency>
      <groupId>trove</groupId>
      <artifactId>trove</artifactId>
      <version>1.1-beta-5</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-aop</artifactId>
      <version>2.0.0.alpha2</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-common</artifactId>
      <version>4.0.2</version>
    </dependency>
    <dependency>
      <groupId>concurrent</groupId>
      <artifactId>concurrent</artifactId>
      <version>1.3.4</version>
    </dependency>


About strong fealings !!!!!!
====================
1) Yes I have strong fealings, I do belive that the plugin should not add any artifact to the end product (or client-artifact) "behind the schenes" --> such things will end up in errors.

2) A rule is that the plugin should NOT be in the client dependency list.
I have worked quite a lot with maven2 and I have never seen this before :-)


3) At the same time the compile time artifacts that AOPC uses, ant the client NOT uses, should not be in the client-artifact as well.....
Therefore we are not finished yet :-)




> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 02:40:05 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Aug 2007 02:40:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14777820.1186641605928.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-789:
----------------------------

    Attachment: jboss-remoting.jar

Attached jboss-remoting.jar with fixes for all issues associated with Remoting 2.2.0.SP1 release.  It represents the state of the remoting_2_2_0_GA branch at tag remoting_2_2_1_SP1_Beta.

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.SP1
>
>         Attachments: jboss-remoting.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 lists.jboss.org  Thu Aug  9 02:55:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 02:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1127272.1186642549659.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers reopened GPD-78:
--------------------------

             

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Thu Aug  9 02:55:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 02:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18601869.1186642549840.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers updated GPD-78:
-------------------------

        Fix Version/s: jBPM JPDL Designer 3.1.0.GA
                           (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s: jBPM JPDL Designer 3.1.0.CR
                           (was: jBPM JPDL Designer 3.1.0.beta2)

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Thu Aug  9 03:48:49 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Thu, 9 Aug 2007 03:48:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4587) NoClassDefFoundError
 java.lang.System
In-Reply-To: <6030030.1185874069379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32478936.1186645729407.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Aleksandar Kostadinov updated JBAS-4587:
----------------------------------------

    Comment: was deleted

> NoClassDefFoundError java.lang.System
> -------------------------------------
>
>                 Key: JBAS-4587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4587
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions:  JBossAS-5.0.0.Beta3
>         Environment: QA Lab, VM, Sun JDK 1.5
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Scott M Stark
>         Attachments: server_log.zip, server_log_1.zip
>
>
> In the QA Lab we come across an issue when trying to run the JBoss AS test suite on VMs (see trace level log bolow). Consequences are that minimal server doesn't shutdown and test suite fails on starting the all configuration.
> To reproduce:
> Can be reproduced on a VM with sun jdk15 versions including 1.5.0_12. 
> Try ssh to qa01.qa.atl.jboss.com. On any issue ask in jboss-qa-internal at redhat.com or #jbossqa
> Checkout trunk.
> build/build.sh
> testsuite/build.sh jboss-minimal-tests
> The issue doesn't occur on physical machines as well jrockit is not affected.
> If that could be of any help I've found two issues with java.lang.System not found and gcj.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6371479
> http://www.linuxhelpforum.com/showthread.php?t=809687
> 2 server trace logs attached. Part of log see below:
> 2007-07-31 05:04:11,222 DEBUG [org.jboss.deployers.plugins.deployers.DeployersIm
> pl] Fully Undeployed vfsfile:/qa/services/hudson/hudson_workspace/workspace/JBos
> s_AS_Testsuite_HEAD-jdk15/src/build/output/jboss-5.0.0.Beta3/server/minimal/depl
> oy/shutdown.sar
> 2007-07-31 05:04:11,223 TRACE [org.jboss.system.server.profileservice.hotdeploy.
> HDScanner] End deployment scan
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=0
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=1
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,224 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,225 ERROR [STDERR] Exception in thread "ExitOnShutdown"
> 2007-07-31 05:04:11,226 ERROR [STDERR] java.lang.NoClassDefFoundError: java/lang
> /System
> 2007-07-31 05:04:11,226 ERROR [STDERR]  at org.jboss.test.jmx.shutdown.ExitOnShu
> tdown$1.run(ExitOnShutdown.java:52)
> 2007-07-31 05:04:11,227 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 lists.jboss.org  Thu Aug  9 05:50:49 2007
From: jira-events at lists.jboss.org (Mariusz Olejnik (JIRA))
Date: Thu, 9 Aug 2007 05:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1037)
 JDBCPersistenceManager.java - reference should be inserted after message
 (ORA-02291: integrity constraint)
Message-ID: <21939514.1186653049587.JavaMail.jira@cloud.prod.atl2.jboss.com>

JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)
----------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1037
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037
             Project: JBoss Messaging
          Issue Type: Patch
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
         Environment: Windows XP / Oracle 10g
            Reporter: Mariusz Olejnik
         Assigned To: Tim Fox
            Priority: Critical
             Fix For: 1.4.0.CR1


Reference should be inserted after message because:
oracle-persistence-service.xml 
CREATE TABLE JBM_MSG_REF (
  CHANNEL_ID INTEGER, 
  MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) 
[...]



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 05:53:49 2007
From: jira-events at lists.jboss.org (Mariusz Olejnik (JIRA))
Date: Thu, 9 Aug 2007 05:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1037)
 JDBCPersistenceManager.java - reference should be inserted after message
 (ORA-02291: integrity constraint)
In-Reply-To: <21939514.1186653049587.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10510671.1186653229494.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mariusz Olejnik updated JBMESSAGING-1037:
-----------------------------------------

    Attachment: jboss-messaging-trunk-rev2988.patch

addReference(channelID, ref, psReference, false);
^
|
v
updateWithRetry(psMessage);

> JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1037
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>         Environment: Windows XP / Oracle 10g
>            Reporter: Mariusz Olejnik
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.4.0.CR1
>
>         Attachments: jboss-messaging-trunk-rev2988.patch
>
>
> Reference should be inserted after message because:
> oracle-persistence-service.xml 
> CREATE TABLE JBM_MSG_REF (
>   CHANNEL_ID INTEGER, 
>   MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) 
> [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 06:28:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 06:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1038) Client side
 failover hopping does not work
Message-ID: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>

Client side failover hopping does not work
------------------------------------------

                 Key: JBMESSAGING-1038
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.

if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".

Instead it should iterate through the list of delegates trying each one in turn.

Need to write a test for this 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 lists.jboss.org  Thu Aug  9 07:04:02 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1039) HTTP poller
	doesn't stop
Message-ID: <3265708.1186657442806.JavaMail.jira@cloud.prod.atl2.jboss.com>

HTTP poller doesn't stop
------------------------

                 Key: JBMESSAGING-1039
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1039
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


I have temporarily commented out clusterviewupdatetst::testUpdateMixedConnectionFactory since, once started, the HTTP poller doesn't stop.

Maybe this is a bug in remoting - need to investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 07:05:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 07:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1040) Update to
	Java 5 GUIDs
Message-ID: <11730897.1186657549288.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to Java 5 GUIDs
----------------------

                 Key: JBMESSAGING-1040
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1040
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 1


Since we are now Java 5 only, we can update to Java 5 guids.

We can also get rid of the message id generator 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 lists.jboss.org  Thu Aug  9 07:55:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 07:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26551267.1186660549359.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371598 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

I just downloaded a brand new Eclipse 3.3.0, Build : I20070625-1500, on my macbook pro, and installed JPDL Designer Plug-in 3.1.0 CR1, started a new jbpm project, created a new process definition, and straight away got the same error, so this is happening out of the box effectively on OSX.

Regards

Ross


> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 07:59:06 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 07:59:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1041) Bug in client
 side failover map updating
Message-ID: <24570873.1186660746148.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bug in client side failover map updating
----------------------------------------

                 Key: JBMESSAGING-1041
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1041
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Consider this scenario:

There are three nodes in the cluster: 0, 1, 2.

Failover map is as follows:

0-->1
1-->2
2-->0

There is a connection on node 1.

Node 1 is killed.

Node 2 fails over for node 1.

An update is then sent to the client with the new failover map:

0-->2

2-->0

Client side failure is then detected

The client attempts failover, but there is no failover node specified in the map any more, since it has been updated.

Client fails to failover



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 07:59:06 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 07:59:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5070798.1186660746267.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371599 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

Can you attach the Eclipse log? Make sure you first remove everything that is not related to this issue.

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 08:00:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 08:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1041) Bug in
 client side failover map updating
In-Reply-To: <24570873.1186660746148.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31266400.1186660849781.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

One solution to this, is not to overwrite the failovermap when the update occurs, but to *add* to the current map.

I.e the failover map on the client side after failover would read:

0-->2

1-->2

2-->0

So the client can still find the node after failure.

> Bug in client side failover map updating
> ----------------------------------------
>
>                 Key: JBMESSAGING-1041
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1041
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Consider this scenario:
> There are three nodes in the cluster: 0, 1, 2.
> Failover map is as follows:
> 0-->1
> 1-->2
> 2-->0
> There is a connection on node 1.
> Node 1 is killed.
> Node 2 fails over for node 1.
> An update is then sent to the client with the new failover map:
> 0-->2
> 2-->0
> Client side failure is then detected
> The client attempts failover, but there is no failover node specified in the map any more, since it has been updated.
> Client fails to failover

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 08:17:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 08:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16719767.1186661869457.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371605 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

in the log, each time I see this error I get the following:

Message : Problems occurred when invoking code from plug-in: "org.eclipse.jface", Plug-in: org.eclipse.jface, Date : 2007-........

I am not sure how to view a more detailed log,

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 08:34:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 08:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1041) Bug in client
 side failover map updating
In-Reply-To: <24570873.1186660746148.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15741301.1186662889302.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1041.
--------------------------------

    Resolution: Done

> Bug in client side failover map updating
> ----------------------------------------
>
>                 Key: JBMESSAGING-1041
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1041
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Consider this scenario:
> There are three nodes in the cluster: 0, 1, 2.
> Failover map is as follows:
> 0-->1
> 1-->2
> 2-->0
> There is a connection on node 1.
> Node 1 is killed.
> Node 2 fails over for node 1.
> An update is then sent to the client with the new failover map:
> 0-->2
> 2-->0
> Client side failure is then detected
> The client attempts failover, but there is no failover node specified in the map any more, since it has been updated.
> Client fails to failover

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 08:43:00 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Aug 2007 08:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-572) PIGGYBACK
Message-ID: <23476376.1186663380304.JavaMail.jira@cloud.prod.atl2.jboss.com>

PIGGYBACK
---------

                 Key: JGRP-572
                 URL: http://jira.jboss.com/jira/browse/JGRP-572
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.x


Oftentimes, JGroups sends messages which have only headers but no payload. These messages (e.g. heartbeats, stability/stable messages) could use another message to piggy back on. Or - if no regular message is sent within a certain timeout - all accumulated piggy back messages could be merged into one.
The advantage is that we send less traffic.
Implementation could be via a flag PIGGYBACK (same as OOB) in Message, and a protocol PIGGYBACK. The protocol accumulates all messages with the flag PIGGYBACK set, and attaches them to a regular message, or - when a timeout elapses - merges as many of the piggy back messages as possible and sends them as one message.

Note that this is not the same as the old PIGGYBACK protocol which used to be in JGroups a long time ago.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 09:16:55 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 09:16:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10835248.1186665415791.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371607 ] 
            
Paul Gier commented on JBAOP-453:
---------------------------------

If you want to add dependencies for the plugin to use that will not be included in the project artifact dependencies, you can add those dependencies to the plugin configuration.
For example:
  <plugin>
    <artifactId>maven-jbossaop-plugin</artifactId>
    <dependencies>
      <dependency>
        ...
      </dependency>
    </dependencies>
  </plugin>

Will that help your issue?

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 09:39:13 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 09:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14500762.1186666753531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371609 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

Doubleclick on the item in the Error Log View. A dialog will show up containing the stack trace.

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 09:40:50 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Thu, 9 Aug 2007 09:40:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6349767.1186666850014.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sohil Shah reopened JBPORTAL-1146:
----------------------------------

      Assignee: Sohil Shah  (was: Roy Russo)
             

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.6.Alpha1
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 09:50:49 2007
From: jira-events at lists.jboss.org (Tong Lee (JIRA))
Date: Thu, 9 Aug 2007 09:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5160227.1186667449403.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12371610 ] 
            
Tong Lee commented on JBRULES-1065:
-----------------------------------

Thanks for your reply and I agree your example works and it's not a bug.

Our issue is, we're trying to do  the following...

rule "auto binding ..."
when
  $c : Cheese ( price > weight )
then
  results.add( $c );
end

In above example, the PackageBuilder throws an Exception - Unable to return Declaration for identifier "weight".


> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Mark Proctor
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Thu Aug  9 09:50:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 09:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1042) Investigate
 possible casting issue with message bridge
Message-ID: <5137497.1186667449514.JavaMail.jira@cloud.prod.atl2.jboss.com>

Investigate possible casting issue with message bridge
------------------------------------------------------

                 Key: JBMESSAGING-1042
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1042
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 10:08:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 10:08:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19571762.1186668529354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-138?page=all ]

Ross McDonald reopened GPD-138:
-------------------------------

             
attaching stacktrace 

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 10:10:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 10:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-138) error dialogue appears
 on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13945699.1186668649371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-138?page=all ]

Ross McDonald updated GPD-138:
------------------------------

    Attachment: stacktrace.txt

stacktrace attached

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 11:23:49 2007
From: jira-events at lists.jboss.org (Linoux Linoux (JIRA))
Date: Thu, 9 Aug 2007 11:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4598) TimerHandle failed
 to retrieve timer after JBoss restart
Message-ID: <103417.1186673029432.JavaMail.jira@cloud.prod.atl2.jboss.com>

TimerHandle failed to retrieve timer after JBoss restart
--------------------------------------------------------

                 Key: JBAS-4598
                 URL: http://jira.jboss.com/jira/browse/JBAS-4598
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.5.GA
         Environment: Windows XP / PostgreSQL
            Reporter: Linoux Linoux


Creating a timer, store the associated TimerHandle in DB.
Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.

----------------------------------------------------------
//In a Stateless Session :

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void createTimer() throws OgpException {
    TimerService ts = ctx.getTimerService();
    Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
    conf.setTestCleanTimerHandle(newTimer.getHandle());
    
    // Store conf in DB
}

private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
    if (conf.getTestCleanTimerHandle() == null)
      return null;
    try {
      return conf.getTestCleanTimerHandle().getTimer();
    } catch (NoSuchObjectLocalException e) {
        log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
       return null;
    }
}
----------------------------------------------------------

Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :

javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
        at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
        at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
        [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 11:32:49 2007
From: jira-events at lists.jboss.org (Linoux Linoux (JIRA))
Date: Thu, 9 Aug 2007 11:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4598) TimerHandle failed
 to retrieve timer after JBoss restart
In-Reply-To: <103417.1186673029432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9549690.1186673569351.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Linoux Linoux updated JBAS-4598:
--------------------------------

    Description: 
Creating a timer, store the associated TimerHandle in DB.
Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.

----------------------------------------------------------
//In a Stateless Session :

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void createTimer() throws OgpException {
    TimerService ts = ctx.getTimerService();
    Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
    conf.setTestCleanTimerHandle(newTimer.getHandle());
    
    // Store conf in DB
}

private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
    if (conf.getTestCleanTimerHandle() == null)
      return null;
    try {
      return conf.getTestCleanTimerHandle().getTimer();
    } catch (NoSuchObjectLocalException e) {
        log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
       return null;
    }
}
----------------------------------------------------------

Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :

javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
        at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
        at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
        [...]

JBoss uses the PostgreSQL database to store the timers and all other stuff. I have noted that the timers.timerid field changed after restarting JBoss, that could explain why the Timer is not found by the TimerHandle...

  was:
Creating a timer, store the associated TimerHandle in DB.
Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.

----------------------------------------------------------
//In a Stateless Session :

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void createTimer() throws OgpException {
    TimerService ts = ctx.getTimerService();
    Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
    conf.setTestCleanTimerHandle(newTimer.getHandle());
    
    // Store conf in DB
}

private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
    if (conf.getTestCleanTimerHandle() == null)
      return null;
    try {
      return conf.getTestCleanTimerHandle().getTimer();
    } catch (NoSuchObjectLocalException e) {
        log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
       return null;
    }
}
----------------------------------------------------------

Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :

javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
        at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
        at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
        [...]


> TimerHandle failed to retrieve timer after JBoss restart
> --------------------------------------------------------
>
>                 Key: JBAS-4598
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4598
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows XP / PostgreSQL
>            Reporter: Linoux Linoux
>
> Creating a timer, store the associated TimerHandle in DB.
> Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.
> ----------------------------------------------------------
> //In a Stateless Session :
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void createTimer() throws OgpException {
>     TimerService ts = ctx.getTimerService();
>     Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
>     conf.setTestCleanTimerHandle(newTimer.getHandle());
>     
>     // Store conf in DB
> }
> private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
>     if (conf.getTestCleanTimerHandle() == null)
>       return null;
>     try {
>       return conf.getTestCleanTimerHandle().getTimer();
>     } catch (NoSuchObjectLocalException e) {
>         log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
>        return null;
>     }
> }
> ----------------------------------------------------------
> Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :
> javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
>         at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
>         at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
>         [...]
> JBoss uses the PostgreSQL database to store the timers and all other stuff. I have noted that the timers.timerid field changed after restarting JBoss, that could explain why the Timer is not found by the TimerHandle...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 11:41:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 9 Aug 2007 11:41:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29264517.1186674109427.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

autovivification is only supported for return value and inline-evals. We further support nested property accessors, liek in the above example I pasted, and your first post. We don't support autovivification of any field. We won't fix this for the point release too, as its really a new feature request. I'll re-open this as a request for FUTURE.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Mark Proctor
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Thu Aug  9 11:43:49 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 9 Aug 2007 11:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1065) Unable to return
 Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25436721.1186674229649.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1065:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Thu Aug  9 14:39:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 14:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1043) Make sure all
 examples work out of distro
Message-ID: <3531415.1186684741123.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make sure all examples work out of distro
-----------------------------------------

                 Key: JBMESSAGING-1043
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1043
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:39:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 14:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1044) Cleanup docs
 using xml editor
Message-ID: <5895634.1186684741257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cleanup docs using xml editor
-----------------------------

                 Key: JBMESSAGING-1044
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1044
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:45:01 2007
From: jira-events at lists.jboss.org (Dr. Gernot Starke (JIRA))
Date: Thu, 9 Aug 2007 14:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1068) Exception when
 adding
 "activation-group" attribute to otherwise correctly executed rule...
Message-ID: <25370522.1186685101163.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception when adding "activation-group" attribute to otherwise correctly executed rule...
------------------------------------------------------------------------------------------

                 Key: JBRULES-1068
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1068
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Eclipse 3.2
            Reporter: Dr. Gernot Starke
         Assigned To: Mark Proctor


rule "Golfer-Riddle with a single solution?" 
	activation-group="unique-solution"
    when
        // There is a golfer names Fred, 
        $f: Golfer( name == "Fred",
...

yields:
Exception in thread "main" org.drools.compiler.DroolsParserException: Unknown error while parsing. This is a bug. Please contact the Development team.
	at org.drools.compiler.DrlParser.compile(DrlParser.java:180)
	at org.drools.compiler.DrlParser.parse(DrlParser.java:61)
	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:19)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:47:01 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 9 Aug 2007 14:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1069) DSL sentence
 widget is too
 small and combobox with sentences should not be expanded
Message-ID: <21523644.1186685221254.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL sentence widget is too small and combobox with sentences should not be expanded
-----------------------------------------------------------------------------------

                 Key: JBRULES-1069
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1069
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Ahti Kitsik
         Assigned To: Ahti Kitsik
            Priority: Minor
             Fix For: 4.0.1


Reported by Kris Verlaenen:
There is still an issue with DSL in the guided editor:
if you add a DSL sentence, fill in some values, and then try to add
more sentences, the sentences shown in the drop-down box also contain
the filled in values ?

The size of the boxes in DSL sentences also seem to shrink to minimal
when adding new sentences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:47:01 2007
From: jira-events at lists.jboss.org (Dr. Gernot Starke (JIRA))
Date: Thu, 9 Aug 2007 14:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
Message-ID: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception with "not in" condition with  (int-values)
----------------------------------------------------

                 Key: JBRULES-1070
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions:  4.0.0.GA
         Environment: Eclipse 3.2
            Reporter: Dr. Gernot Starke
         Assigned To: Mark Proctor


// Bob wears plaid       
Golfer( name == "Bob", 
        $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
        $bobsColor : color == "plaid",
        color != $fredsColor, color != $joesColor,
        color != $fredsNeighbourColor )

yields the following exception
Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 15:21:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 15:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4599) JaasSecurityManager
	refactor
Message-ID: <19316533.1186687261058.JavaMail.jira@cloud.prod.atl2.jboss.com>

JaasSecurityManager refactor
----------------------------

                 Key: JBAS-4599
                 URL: http://jira.jboss.com/jira/browse/JBAS-4599
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For:  JBossAS-5.0.0.Beta3


JaasSecurityManager extends ServiceMBeanSupport. It needs to be refactor such that it reuses a bean from the security 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 lists.jboss.org  Thu Aug  9 15:31:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Aug 2007 15:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14838528.1186687861064.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-789:
----------------------------

    Attachment: jboss-remoting.jar

Attached new jboss-remoting.jar without extraneous log.info messages.

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.SP1
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Thu Aug  9 15:33:03 2007
From: jira-events at lists.jboss.org (Vladimir Schafer (JIRA))
Date: Thu, 9 Aug 2007 15:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1071)
 BinaryRuleBaseLoader doesn't accept custom ClassLoader
Message-ID: <2403729.1186687983991.JavaMail.jira@cloud.prod.atl2.jboss.com>

BinaryRuleBaseLoader doesn't accept custom ClassLoader
------------------------------------------------------

                 Key: JBRULES-1071
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1071
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Vladimir Schafer
         Assigned To: Mark Proctor
            Priority: Minor


AddPackage method of class BinaryRuleBaseLoader accepts custom classloader as a parameter, but this isn't propagated to DroolsObjectInputStream in addPackage method call. So custom class loading isn't available when constructing RuleBases from JBRMS packaged files.

Error is in file org.drools.util.BinaryRuleBaseLoader.java, Core module, line 81. Code ObjectInputStream oin = new DroolsObjectInputStream( in ); should be changed to ObjectInputStream oin = new DroolsObjectInputStream( in, classLoader ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 15:50:03 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 9 Aug 2007 15:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4600) Rename JBossMQ
 variables from
 jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into
 build-thirdparty
Message-ID: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty
---------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4600
                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: JBossAS-4.2.2.GA


It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 16:29:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 9 Aug 2007 16:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23049806.1186691341306.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371667 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Hi Again

I have now studiet the maven-compiler-plugin and discoverd how <scope>provided</scope> works.

The secret is to add compile to the  @requiresDependencyResolution annotation.


 * @requiresDependencyResolution compile

So with this fix I think JBAOP-453 can be solved

I have not tried Paul Giers suggestion.

One reason for this is that I do not know the reasoning for 4 dependencies.
For each artifact it is necessary to know which is AOPC compiler required and/or runtime required.????

If you fix the @requiresDependencyResolution  I think the problem is solved :-)

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 16:43:01 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Thu, 9 Aug 2007 16:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
Message-ID: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>

Installation / Build instructions do not match what SVN delivers
----------------------------------------------------------------

                 Key: JBRULES-1072
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.MR3
         Environment: WinXP on Dell desktop
            Reporter: Dave Dibble
         Assigned To: Mark Proctor


Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.

There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.

Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
C:\dev\jbossrules\drools-eclipse>ant clean-all
Buildfile: build.xml

BUILD FAILED
Target "clean-all" does not exist in the project "Build All Elements".

Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.

Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 16:46:19 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 9 Aug 2007 16:46:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28311835.1186692379568.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371669 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

I have now tried Paul Geirs solution

Below I have moved the 4 dependencies to the artifact.
error java.lang.NoClassDefFoundError: gnu/trove/TLongObjectHashMap tells me that the dependency list under the plugin does not appear on the CP by default.

But good news is that   Plugin plugin=(Plugin)project.getBuild().getPlugins().get(1);
plugin.getDependencies() --> list the four dependencyies !!!!!!!

So the problem is to add these also  --> very good solution.
I have a problem to find "current" plugin !!!! 
In my program it is nr 1 in the plugin list. I belive there is an instance current-plugin "sonewhere"

/Anders

  <build>
    <plugins>
      <plugin>
        <groupId>org.jboss.maven.plugins</groupId>
        <artifactId>maven-jbossaop-plugin</artifactId>
        <version>1.0-SNAPSHOT</version>
        <dependencies>
          <dependency>
            <groupId>trove</groupId>
            <artifactId>trove</artifactId>
            <version>1.1-beta-5</version>
          </dependency>
          <dependency>
            <groupId>jboss</groupId>
            <artifactId>jboss-aop</artifactId>
            <version>2.0.0.alpha2</version>
          </dependency>
          <dependency>
            <groupId>jboss</groupId>
            <artifactId>jboss-common</artifactId>
            <version>4.0.2</version>
          </dependency>
          <dependency>
            <groupId>concurrent</groupId>
            <artifactId>concurrent</artifactId>
            <version>1.3.4</version>
          </dependency>
        </dependencies>
        <executions>
          <execution>
            <phase>process-classes</phase>
            <configuration>
              <aoppath>${basedir}/../portal-wsrp-sar/src/main/resources/wsrp-aop.xml</aoppath>
              <verbose>true</verbose>
              <includes>
                <include>org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class</include>
              </includes>
            </configuration>
            <goals>
              <goal>compile</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>


> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 16:52:03 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Thu, 9 Aug 2007 16:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
In-Reply-To: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10892638.1186692723110.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1072?page=comments#action_12371671 ] 
            
Dave Dibble commented on JBRULES-1072:
--------------------------------------

It would appear that the documentation found at http://labs.jboss.com/auth/jbossrules/docs/index.html is different to what is retrieved from svn in a number of regards - the current svn documentation indicates a maven download is needed and different commands are used for the build. 

Would be nice to get a confirmation that the doc on the jboss website is out of date.

> Installation / Build instructions do not match what SVN delivers
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1072
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP on Dell desktop
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>
> Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.
> There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.
> Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
> C:\dev\jbossrules\drools-eclipse>ant clean-all
> Buildfile: build.xml
> BUILD FAILED
> Target "clean-all" does not exist in the project "Build All Elements".
> Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
> eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.
> Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 17:19:20 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Thu, 9 Aug 2007 17:19:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23596227.1186694360587.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

John Ruud updated GPD-78:
-------------------------


Koen,

Here's some of my node samples (as you can see they're similar to Imran's in complexity):

   <nodeSign name="nodeSign1">
      <action class="com.xyz.ActionSign">
         <MyTag>
            <SignatureType></SignatureType>
         </MyTag>
      </action>
   </nodeSign>

   <decideIsTime name="decision3">
      <handler class="com.xyz.DecideIsTime">
         <MyTag>
            <CompareDate>
               <DateTime format="HH:mm" operator="between"></DateTime>
            </CompareDate>
         </MyTag>
      </handler>
   </decideIsTime>

   <state name="state1">
      <event type="node-enter">
         <action class="com.xyz.SetTask">
            <MyTag>
               <ProcessingTypeID></ProcessingTypeID>
            </MyTag>
         </action>
      </event>
      <event type="node-leave">
         <action class="com.xyz.SetTaskClear"></action>
      </event>
   </state>

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Thu Aug  9 17:28:02 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Thu, 9 Aug 2007 17:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18013360.1186694882400.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371677 ] 
            
John Ruud commented on GPD-128:
-------------------------------

Koen,

The following method of mine no longer compiles, as XmlAdapterRegistry.getConfigurationElementByXmlElementName(String) no longer exists. Do you happen to know off the top of your head what the replacement would be (I haven't had the time to study your latest batch of changes yet, but I suspect there's probably better ways of doing this):

private static String getSemanticElementId(String elementName, SemanticElement parent) {
		XmlAdapterRegistry registry = RegistryRegistry.getXmlAdapterRegistry(parent.getFactory().getEditorId());
		IConfigurationElement configurationElement = 
			registry.getConfigurationElementByXmlElementName(elementName);
		if (configurationElement == null) 
			return null;
		return configurationElement.getAttribute("semanticElement");
	}

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Thu Aug  9 17:44:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-45) Assimilate the
 Higgins Project SPI
In-Reply-To: <17842793.1177708650271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6181578.1186695841134.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana updated SECURITY-45:
----------------------------------

    Fix Version/s: 2.0.2-GA
                       (was: 2.0.1.BETA)

> Assimilate the Higgins Project SPI
> ----------------------------------
>
>                 Key: SECURITY-45
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-45
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.2-GA
>
>
> There is a need to get the SPI for Project Higgins Trust Framework into the JBoss Security SPI.
> http://www.eclipse.org/higgins/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 17:44:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-30) Validate
 security_policy_5.0.xsd for JBAS
In-Reply-To: <30779788.1173285623901.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14446464.1186695841278.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-30?page=all ]

Anil Saldhana updated SECURITY-30:
----------------------------------

    Fix Version/s: 2.0.1
                       (was: 2.0.1.BETA)

> Validate security_policy_5.0.xsd for JBAS
> -----------------------------------------
>
>                 Key: SECURITY-30
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-30
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.0.BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1
>
>
> With the JSR-196 work taking the back-seat, there is a need to validate the security config xsd for JBoss5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 17:46:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-41)
 JaasSecurityManagerService can
 show security provider/JCA algorithm information
In-Reply-To: <1401723.1175187486851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19940783.1186695961269.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-41?page=all ]

Anil Saldhana updated SECURITY-41:
----------------------------------

    Fix Version/s: 2.0.1
                       (was: 2.0.1.BETA)

> JaasSecurityManagerService can show security provider/JCA algorithm information
> -------------------------------------------------------------------------------
>
>                 Key: SECURITY-41
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-41
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.0.BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: 2.0.1
>
>
> JBAS-3400 has the 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 lists.jboss.org  Thu Aug  9 17:48:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-73) Release Security
	V2.0.1-BETA
In-Reply-To: <14609963.1186178033997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <647649.1186696081047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-73?page=all ]

Anil Saldhana closed SECURITY-73.
---------------------------------

    Resolution: Done

SPI archives are at:
http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/jboss/jboss-security-spi/2.0.1-BETA/

JBossSX archives are at:
http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/jboss/jbosssx/2.0.1-BETA/

Source Code tags:
http://anonsvn.jboss.org/repos/jbossas/projects/security/

> Release Security V2.0.1-BETA
> ----------------------------
>
>                 Key: SECURITY-73
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-73
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1.BETA
>
>
> Release v2.0.1-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 lists.jboss.org  Thu Aug  9 18:09:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-375) Change surefire
 plugin to accept package names when running a single test.
In-Reply-To: <528775.1180706408529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28801201.1186697341100.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-375?page=all ]

Paul Gier closed JBBUILD-375.
-----------------------------

    Resolution: Done

Surefire plugin has been patched.

> Change surefire plugin to accept package names when running a single test.
> --------------------------------------------------------------------------
>
>                 Key: JBBUILD-375
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-375
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Currently the surefire plugin only accepts a slash delimited path when running a single test.
> mvn -Dtest=org/jboss/test/SomeTestCase test
> This should also accept a package path like this
> mvn -Dtest=org.jboss.test.SomeTestCase 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 lists.jboss.org  Thu Aug  9 18:14:15 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 18:14:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-72) i am getting the
 belwo error when i am trying to invalidate sessio object
In-Reply-To: <25399205.1185220907154.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18791498.1186697655278.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-72?page=all ]

Anil Saldhana closed SECURITY-72.
---------------------------------

    Resolution: Won't Fix

File in the AS forums.  If you do not need the SessionFlushListener, remove it from the web.xml in  the tomcat directory in deploy folder.

> i am getting the belwo error when i am trying to invalidate sessio object
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-72
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-72
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: v v
>         Assigned To: Anil Saldhana
>            Priority: Critical
>
> 2007-07-23 15:35:57,364 DEBUG [org.jboss.web.tomcat.security.SecurityFlushSessionListener] Obtaining SecurityManagerService failed::
> javax.naming.NameNotFoundException: securityMgr 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 org.jnp.server.NamingServer.lookup(NamingServer.java:270)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:270)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:716)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.web.tomcat.security.SecurityFlushSessionListener.getSecurityManagerService(SecurityFlushSessionListener.java:193)
> 	at org.jboss.web.tomcat.security.SecurityFlushSessionListener.getSubjectAndSecurityDomain(SecurityFlushSessionListener.java:160)
> 	at org.jboss.web.tomcat.security.SecurityFlushSessionListener.sessionDestroyed(SecurityFlushSessionListener.java:79)
> 	at org.apache.catalina.session.StandardSession.expire(StandardSession.java:687)
> 	at org.apache.catalina.session.StandardSession.expire(StandardSession.java:645)
> 	at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1090)
> 	at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:149)
> 	at com.standardandpoors.apps.defaultfilter.authentication.DefaultFilterLogoutHandler.execute(DefaultFilterLogoutHandler.java:55)
> 	at com.standardandpoors.framework.controller.BusinessLogicControllerBean.process(BusinessLogicControllerBean.java:170)
> 	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.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
> 	at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:64)
> 	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.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
> 	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.SessionContainer.internalInvoke(SessionContainer.java:648)
> 	at org.jboss.ejb.Container.invoke(Container.java:954)
> 	at sun.reflect.GeneratedMethodAccessor108.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.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
> 	at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
> 	at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:206)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:192)
> 	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 	at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 	at $Proxy205.process(Unknown Source)
> 	at com.standardandpoors.framework.controller.SpControllerServlet.doPost(SpControllerServlet.java:354)
> 	at com.standardandpoors.apps.defaultfilter.controller.DefaultFilterControllerServlet.doPost(DefaultFilterControllerServlet.java:81)
> 	at com.standardandpoors.framework.controller.SpControllerServlet.service(SpControllerServlet.java:255)
> 	at com.standardandpoors.apps.defaultfilter.controller.DefaultFilterControllerServlet.service(DefaultFilterControllerServlet.java:56)
> 	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 com.standardandpoors.apps.defaultfilter.security.JaasLoginFilter.doFilter(JaasLoginFilter.java:266)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at com.standardandpoors.apps.defaultfilter.controller.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:65)
> 	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.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
> 	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 lists.jboss.org  Thu Aug  9 18:22:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-382) Testrun of a
 project with
 circular dependencies errantly includes older version of itself
In-Reply-To: <20419530.1181768651657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3940866.1186698121157.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBBUILD-382?page=comments#action_12371685 ] 
            
Paul Gier commented on JBBUILD-382:
-----------------------------------

I wonder if the issue was related to this:
http://jira.codehaus.org/browse/SUREFIRE-61

Because looking at the test classpath, it looks like the local classes should have come first before the dependency.
The issue above caused the classpath ordering to be changed when the surefire plugin forked.

> Testrun of a project with circular dependencies errantly includes older version of itself
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-382
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-382
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: Maven
>            Reporter: Jason T. Greene
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> jboss-common-core has a dependency on jboss-test
>  <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-test</artifactId>
>       <version>1.0.3.GA</version>
>       <scope>test</scope>
>     </dependency>
> jboss-test has a dependancy on jboss-common-core
> <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common-core</artifactId>
>       <version>2.0.4.GA</version>
>     </dependency>
> This leads to the surefire classpath containing 2 versions of jboss-common-core in the classpath, and unfortunately the older version wins. This means the testsuite never actually runs on the version you are modifying, which is a severe problem. Maven should be smart enough not to include the same artifact-id twice.
> [DEBUG] Test Classpath :
> [DEBUG]   /devel/common-core/trunk/target/classes
> [DEBUG]   /devel/common-core/trunk/target/test-classes
> [DEBUG]   /home/jason/.m2/repository/apache-log4j/log4j/1.2.8/log4j-1.2.8.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-logging-spi/2.0.4.GA/jboss-common-logging-spi-2.0.4.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-log4j/2.0.2.GA/jboss-logging-log4j-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-core/2.0.2.GA/jboss-common-core-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/apache-slide/webdavlib/2.0/webdavlib-2.0.jar
> [DEBUG]   /home/jason/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> [DEBUG]   /home/jason/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/profiler/jvmti/jboss-profiler-jvmti/1.0.0.CR5/jboss-profiler-jvmti-1.0.0.CR5.jar
> [DEBUG]   /home/jason/.m2/repository/apache-xerces/xml-apis/2.7.1/xml-apis-2.7.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-spi/2.0.2.GA/jboss-logging-spi-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/apache-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.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 lists.jboss.org  Thu Aug  9 18:24:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-382) Testrun of a
 project with
 circular dependencies errantly includes older version of itself
In-Reply-To: <20419530.1181768651657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18012594.1186698241137.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-382?page=all ]

Paul Gier closed JBBUILD-382.
-----------------------------

    Resolution: Done

I don't think there is anything more to do on this issue.

> Testrun of a project with circular dependencies errantly includes older version of itself
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-382
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-382
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: Maven
>            Reporter: Jason T. Greene
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> jboss-common-core has a dependency on jboss-test
>  <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-test</artifactId>
>       <version>1.0.3.GA</version>
>       <scope>test</scope>
>     </dependency>
> jboss-test has a dependancy on jboss-common-core
> <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common-core</artifactId>
>       <version>2.0.4.GA</version>
>     </dependency>
> This leads to the surefire classpath containing 2 versions of jboss-common-core in the classpath, and unfortunately the older version wins. This means the testsuite never actually runs on the version you are modifying, which is a severe problem. Maven should be smart enough not to include the same artifact-id twice.
> [DEBUG] Test Classpath :
> [DEBUG]   /devel/common-core/trunk/target/classes
> [DEBUG]   /devel/common-core/trunk/target/test-classes
> [DEBUG]   /home/jason/.m2/repository/apache-log4j/log4j/1.2.8/log4j-1.2.8.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-logging-spi/2.0.4.GA/jboss-common-logging-spi-2.0.4.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-log4j/2.0.2.GA/jboss-logging-log4j-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-core/2.0.2.GA/jboss-common-core-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/apache-slide/webdavlib/2.0/webdavlib-2.0.jar
> [DEBUG]   /home/jason/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> [DEBUG]   /home/jason/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/profiler/jvmti/jboss-profiler-jvmti/1.0.0.CR5/jboss-profiler-jvmti-1.0.0.CR5.jar
> [DEBUG]   /home/jason/.m2/repository/apache-xerces/xml-apis/2.7.1/xml-apis-2.7.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-spi/2.0.2.GA/jboss-logging-spi-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/apache-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.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 lists.jboss.org  Thu Aug  9 18:35:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-369) Work on a site
 plugin configuration that follows the jboss.org look and feel.
In-Reply-To: <2354415.1178727472297.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1101035.1186698901073.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-369?page=all ]

Paul Gier updated JBBUILD-369:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Work on a site plugin configuration that follows the jboss.org look and feel.
> -----------------------------------------------------------------------------
>
>                 Key: JBBUILD-369
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-369
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Create a maven skin with the look of the new jboss.org.
> Figure out how the maven generated sites should be deployed to jboss.org.
> Add reporting configuration to the jboss parent pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 19:12:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 19:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-369) Integration
 between maven generated sites and jboss.org
In-Reply-To: <2354415.1178727472297.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6886837.1186701121056.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-369?page=all ]

Paul Gier updated JBBUILD-369:
------------------------------

    Summary: Integration between maven generated sites and jboss.org  (was: Work on a site plugin configuration that follows the jboss.org look and feel.)

> Integration between maven generated sites and jboss.org
> -------------------------------------------------------
>
>                 Key: JBBUILD-369
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-369
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Create a maven skin with the look of the new jboss.org.
> Figure out how the maven generated sites should be deployed to jboss.org.
> Add reporting configuration to the jboss parent pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 19:14:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 19:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-391) Create jboss.org
 site for maven-jdocbook-plugin
In-Reply-To: <2058933.1183489497644.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16948477.1186701241071.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBBUILD-391?page=comments#action_12371692 ] 
            
Paul Gier commented on JBBUILD-391:
-----------------------------------

Some css issues still need to be resolved for the site to look good.

> Create jboss.org site for maven-jdocbook-plugin
> -----------------------------------------------
>
>                 Key: JBBUILD-391
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-391
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Steve created the jdocbook plugin for maven.  This should be the new standard docbook configuration within jboss.  A site needs to be created for the plugin documentation on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 00:39:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 00:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7037607.1186720741603.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sohil Shah updated JBPORTAL-1146:
---------------------------------

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

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 01:33:27 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 01:33:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <997021.1186724007844.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sohil Shah updated JBPORTAL-1146:
---------------------------------

    Fix Version/s: 2.8 Final

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.4.2 Final, 2.8 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 01:51:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 01:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14003670.1186725061373.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sohil Shah resolved JBPORTAL-1146.
----------------------------------

    Resolution: Done

The Zip File creation instead of using InputStream directly did the trick.

Also, some issues with properly creating path hierarchy needed fixing which was completely independent of the ZipFile issue 

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.4.2 Final, 2.6.2 Final, 2.8 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 02:00:11 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Fri, 10 Aug 2007 02:00:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14937462.1186725611806.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371698 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

I have been thinking about Paul Geirs comment.
1) I have tried to add a dependency to the plugin that does not exist --> the build fails like a normal missing dependency --> GOOD. We can trust the dependency collection on the plugin.

2) If the user has added plugin-dependencies I simply think we should add it to the "-cp"
     Technically I think we can get the plugin-dependency-list by adding a menber-variable to the MOJO and 
     give it the correct annotation..
     I have not seen this membervariable yet.. But I will search a little for it.

3) If the user has NOT added plugin dependencies. I think we should add all the AOPC internal artifacts It needs to the "-cp"
     Technically this can be done by containing a list of these artifacts in the plugin / plugin's pom.xml and simply add these. I do not know how many it is??
3.a) Here we are back to my problem. I know nothing about AOPC .... You and others must help here ... and document what artifact is AOPC and what artifact is runtime relevant.

4) By this (2+3)  I belive we get the easy functionality you suggested.
5) By this we also keep the dependency system "clean". 
6) By this the user will have to add client-plugin-dependencies as normal if he/she wants it to become runtime dependencies.

7) This also asks for getting the documentation to the plugin done.
8) This also asks for a home-page for the site of the plugin.
9) On page http://labs.jboss.com/jbossaop/ I see a good place for a link to the site for this plugin :-)



> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Fri Aug 10 02:13:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 02:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1609) cms cache
 dependency on cms service is flipped
In-Reply-To: <21687902.1185292727080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16093343.1186726381090.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sohil Shah resolved JBPORTAL-1609.
----------------------------------

    Resolution: Done

> cms cache dependency on cms service is flipped
> ----------------------------------------------
>
>                 Key: JBPORTAL-1609
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1609
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final, 2.4.1 Final, 2.4.1 SP1, 2.6 Final, 2.6.1 Final
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.4.2 Final, 2.4.3 Final, 2.6.2 Final, 2.8 Final
>
>
> The cms cache service currently depends on the portal cms service to start.
> The dependency should be such that portal cms service depends on cms cache service instead.
> Because of this bug, some cache configurations like cacheloader async=true settings seem to fail.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 02:22:39 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 10 Aug 2007 02:22:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-199) Add support
 for propagating TransientManagedObjects from structural deployers
In-Reply-To: <11389462.1185657407363.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17207129.1186726959313.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMICROCONT-199?page=comments#action_12371699 ] 
            
Scott M Stark commented on JBMICROCONT-199:
-------------------------------------------

Done except for the type safe Iterable implementation for multi-dimensional arrays.
See the FIXME in org.jboss.test.metatype.values.test.ArrayValueSupportUnitTestCase.test2DCharArray

> Add support for propagating TransientManagedObjects from structural deployers
> -----------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-199
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-199
>             Project: JBoss MicroContainer
>          Issue Type: Feature Request
>          Components: Deployment
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> We need the ability for a structure deployer to add attachments that can be used as input to regular deployers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 02:24:01 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 10 Aug 2007 02:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-202) Primative
 arrays are not
 handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
In-Reply-To: <17430949.1186533240797.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15419869.1186727041293.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMICROCONT-202?page=comments#action_12371700 ] 
            
Scott M Stark commented on JBMICROCONT-202:
-------------------------------------------

Done except for the type safe Iterable implementation for multi-dimensional arrays.
See the FIXME in org.jboss.test.metatype.values.test.ArrayValueSupportUnitTestCase.test2DCharArray

> Primative arrays are not handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-202
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-202
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: MetaData
>    Affects Versions:  JBossMC_2_0_0 Beta3
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> When looking at obtaining MetaType/MetaValues for primative arrays I see problems with the primitive array type name ("[char" vs "[C") and attempts to cast to Object[] in DefaultMetaValueFactory. The referenced forum discusses the 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 lists.jboss.org  Fri Aug 10 02:24:01 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 10 Aug 2007 02:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-199) Add support
 for propagating TransientManagedObjects from structural deployers
In-Reply-To: <11389462.1185657407363.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19113685.1186727041549.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Scott M Stark updated JBMICROCONT-199:
--------------------------------------

    Comment: was deleted

> Add support for propagating TransientManagedObjects from structural deployers
> -----------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-199
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-199
>             Project: JBoss MicroContainer
>          Issue Type: Feature Request
>          Components: Deployment
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> We need the ability for a structure deployer to add attachments that can be used as input to regular deployers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 04:22:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 04:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3455737.1186734121283.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371702 ] 
            
Koen Aers commented on GPD-128:
-------------------------------

John,

I would need to know what the use case of this method is. The replacement of getConfigurationElementByXmlElementName(String) has been replaced by getConfigurationElementByXmlNode(Node) as I told earlier. In what context are you using this method?

Regards,
Koen 

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Fri Aug 10 04:53:01 2007
From: jira-events at lists.jboss.org (Roland Huss (JIRA))
Date: Fri, 10 Aug 2007 04:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1036) config-type schema
 declaration doesnt accept custom instantiator classes
Message-ID: <1713438.1186735981810.JavaMail.jira@cloud.prod.atl2.jboss.com>

config-type schema declaration doesnt accept custom instantiator classes
------------------------------------------------------------------------

                 Key: JBPM-1036
                 URL: http://jira.jboss.com/jira/browse/JBPM-1036
             Project: JBoss jBPM
          Issue Type: Bug
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: Roland Huss
         Assigned To: Tom Baeyens


Specifying a custom delegation instantiator with a  fully qualified class name like in

<action config-type="com.consol.cmas.workflow.jbpm.exe.SpringInstantiator"
              class="com.consol.cmas.projects.it.workflow.development.AssignCallToReviewerActionHandler"/>
	
doesnt work anymore because the schema allows value from a fixed enumeration only:

<xs:attribute name="config-type" default="field">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="field"/>
            <xs:enumeration value="bean"/>
            <xs:enumeration value="constructor"/>
            <xs:enumeration value="configuration-property"/>
          </xs:restriction>
        </xs:simpleType>
 </xs:attribute>

This contrary to  the relevant code in the Delegation class this should work (and indeed worked in some pre 3.2.1 versions):

Instantiator instantiator = null;
    try {
      // find the instantiator
      instantiator = (Instantiator) instantiatorCache.get(configType);
      if (instantiator == null) {
        // load the instantiator class
        Class instantiatorClass = classLoader.loadClass(configType);
        // instantiate the instantiator with the default constructor
        instantiator = (Instantiator) instantiatorClass.newInstance();
        instantiatorCache.put(configType, instantiator);
      }
    } catch (Exception e) {
      log.error(e);
      throw new JbpmException("couldn't instantiate custom instantiator '" + configType + "'", e);
    }
	
So please either relax the schema restriction (which I highly prefer, since I rely on using a custom instantiator) or remove the possibility to 
use a custom instantiator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 04:57:01 2007
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 10 Aug 2007 04:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8238045.1186736221148.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ales Justin closed JBMICROCONT-123.
-----------------------------------

    Fix Version/s: JBossMC-2.0.0.Beta4
                       (was:  JBossMC-2.2.0.GA)
       Resolution: Done

See Scott's comment on the forum - 1st post 2nd page.

> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>            Priority: Minor
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Fri Aug 10 05:46:01 2007
From: jira-events at lists.jboss.org (Hendra Sasmita (JIRA))
Date: Fri, 10 Aug 2007 05:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1045) Count Message
 With Selector
Message-ID: <25240548.1186739161321.JavaMail.jira@cloud.prod.atl2.jboss.com>

Count Message With Selector
---------------------------

                 Key: JBMESSAGING-1045
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1045
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Destination Manager
            Reporter: Hendra Sasmita
         Assigned To: Tim Fox
            Priority: Optional


QueueService and TopicService have methods listAllMessages with selector. This method will return list of messages.
Sometime operator / administrator wants to know only about the number of messages with certain criteria.
In this case, listAllMessages will become inefficient as it returns full list of messages, therefore another method that return the number only 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 lists.jboss.org  Fri Aug 10 05:52:01 2007
From: jira-events at lists.jboss.org (Hendra Sasmita (JIRA))
Date: Fri, 10 Aug 2007 05:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1046) Edit Messages
 inside Destination
Message-ID: <7418916.1186739521564.JavaMail.jira@cloud.prod.atl2.jboss.com>

Edit Messages inside Destination
--------------------------------

                 Key: JBMESSAGING-1046
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1046
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Destination Manager
            Reporter: Hendra Sasmita
         Assigned To: Tim Fox
            Priority: Optional


For administrative purpose, operators may want to change the message's content and/or properties.
As example, change all message that has content X, with content Y

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 05:54:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Aug 2007 05:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1045) Count Message
 With Selector
In-Reply-To: <25240548.1186739161321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10970030.1186739641094.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-1045:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1

> Count Message With Selector
> ---------------------------
>
>                 Key: JBMESSAGING-1045
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1045
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>            Reporter: Hendra Sasmita
>         Assigned To: Tim Fox
>            Priority: Optional
>             Fix For: 2.0.0 Beta 1
>
>
> QueueService and TopicService have methods listAllMessages with selector. This method will return list of messages.
> Sometime operator / administrator wants to know only about the number of messages with certain criteria.
> In this case, listAllMessages will become inefficient as it returns full list of messages, therefore another method that return the number only 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 lists.jboss.org  Fri Aug 10 05:56:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Aug 2007 05:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1046) Edit Messages
 inside Destination
In-Reply-To: <7418916.1186739521564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2573563.1186739761117.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-1046:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1

> Edit Messages inside Destination
> --------------------------------
>
>                 Key: JBMESSAGING-1046
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1046
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>            Reporter: Hendra Sasmita
>         Assigned To: Tim Fox
>            Priority: Optional
>             Fix For: 2.0.0 Beta 1
>
>
> For administrative purpose, operators may want to change the message's content and/or properties.
> As example, change all message that has content X, with content Y

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:28:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1047)
 ServerPeer.listMessageCountersAsHTML sorted by Name
Message-ID: <3125471.1186741681302.JavaMail.jira@cloud.prod.atl2.jboss.com>

ServerPeer.listMessageCountersAsHTML sorted by Name
---------------------------------------------------

                 Key: JBMESSAGING-1047
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1047
             Project: JBoss Messaging
          Issue Type: Patch
            Reporter: Aslak
         Assigned To: Tim Fox


Added name sort to the MessageCounter list. 

Gives a better overview when having lots of Queue/Topic/Subscriptions 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 lists.jboss.org  Fri Aug 10 06:30:01 2007
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Fri, 10 Aug 2007 06:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
Message-ID: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>

Getting exception org.apache.commons.httpclient.HttpRecoverableException
------------------------------------------------------------------------

                 Key: JBWEB-89
                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
            Reporter: Masao Kato
         Assigned To: Mladen Turk


We are getting this exception .

ERROR [org.apache.catalina.connector.CoyoteAdapter] 
java.lang.StringIndexOutOfBoundsException: String index out of range: 32
        at java.lang.String.substring(String.java:1765)
        at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
        at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
        at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
        at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)
        
I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
I made a patch. 
Is this right?

--- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
+++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
@@ -125,7 +125,7 @@
       int index = oldsessionId.lastIndexOf(".");
       if (index > 0)
       {
-         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
+         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
       }

       String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:30:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1047)
 ServerPeer.listMessageCountersAsHTML sorted by Name
In-Reply-To: <3125471.1186741681302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27683595.1186741801367.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Aslak updated JBMESSAGING-1047:
-------------------------------

    Attachment: jmessage_1047.patch

> ServerPeer.listMessageCountersAsHTML sorted by Name
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1047
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1047
>             Project: JBoss Messaging
>          Issue Type: Patch
>            Reporter: Aslak
>         Assigned To: Tim Fox
>         Attachments: jmessage_1047.patch
>
>
> Added name sort to the MessageCounter list. 
> Gives a better overview when having lots of Queue/Topic/Subscriptions 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 lists.jboss.org  Fri Aug 10 06:32:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1047)
 ServerPeer.listMessageCountersAsHTML sorted by Name
In-Reply-To: <3125471.1186741681302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1251998.1186741921173.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Aslak updated JBMESSAGING-1047:
-------------------------------

    Issue Type: Feature Request  (was: Patch)

> ServerPeer.listMessageCountersAsHTML sorted by Name
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1047
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1047
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Aslak
>         Assigned To: Tim Fox
>         Attachments: jmessage_1047.patch
>
>
> Added name sort to the MessageCounter list. 
> Gives a better overview when having lots of Queue/Topic/Subscriptions 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 lists.jboss.org  Fri Aug 10 06:32:01 2007
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Fri, 10 Aug 2007 06:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1672234.1186741921417.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-89?page=all ]

Masao Kato updated JBWEB-89:
----------------------------

    Attachment: patch.txt

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Mladen Turk
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:37:51 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 10 Aug 2007 06:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-140) when working with
 large process
 definitions, screen jumps to top whenever new nodes added in designer
Message-ID: <12103377.1186742271676.JavaMail.jira@cloud.prod.atl2.jboss.com>

when working with large process definitions, screen jumps to top whenever new nodes added in designer
-----------------------------------------------------------------------------------------------------

                 Key: GPD-140
                 URL: http://jira.jboss.com/jira/browse/GPD-140
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: osx macbook pro, eclipse 3.3.0, designer plugin 3.1.0 beta 1, beta 2, CR1
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Trivial


Hi,

when working with large process diagrams, if I am scrolled down to the bottom of the view, and add a new node, when the screen is updated it jumps back up to the top, so I need to scroll down again.

Obviously when adding many nodes, this costs time, its just a trivial thing.

Cheers

Ross

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:47:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1042) Investigate
 possible casting issue with message bridge
In-Reply-To: <5137497.1186667449514.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11011828.1186742821301.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Aslak updated JBMESSAGING-1042:
-------------------------------

    Attachment: JBMESSAGING-1042.patch

Only set the JbossDestination on the incoming message if it is a known Message. 

Set the JbossDestination on the messageToSend if it is a foreign message (after it has been converted/copied). A Foreign message might not like JbossDestinations.


> Investigate possible casting issue with message bridge
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1042
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1042
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>         Attachments: JBMESSAGING-1042.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 lists.jboss.org  Fri Aug 10 06:50:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Fri, 10 Aug 2007 06:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23226909.1186743001356.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=comments#action_12371711 ] 
            
Antoine Herzog commented on JBPORTAL-1146:
------------------------------------------

Hi,
Thanks...

When I worked on this part, a few mounth ago, I did a enhanced export featured : 

 - it allow to export with managing the locales of the files, so to export/import without taking care of "what locale",  

 - and save the title, description... so this can be restored at the import

 - it store the extra information in some properties files, inside the zip, and the import manage to retrieve the things and restore the files in the cms

 - it is build on the same way the export/import works... just added features in some inherited/copied class.

 - the gui is using some similar/modified jsp... but the choice of one/several locale is not done (all locales always...or only one).

it was working on 2.4.1, but did not tested it on 2.6 (I am migrating things little by little on this new version).

if you think it is of any interest, I can provide all the stuff... for integration in the portal.

but I can do this only on a "as is" basis : just take the things out of my project, and send it.
(I have a huge work to do, first priority, for at least the end of august ... and then the end of the year... so can't contribute more with arranging and preparing the package for easy integration.)



> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:59:30 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 06:59:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16788827.1186743570198.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=comments#action_12371712 ] 
            
Thomas Heute commented on JBPORTAL-1146:
----------------------------------------

Please Antoine, keep in mind that when you contribute your work, it's there to stay.

It means that we maintain it, and you don't have to worry about merging (with potential modifications) your changes again and again across versions, so usually it worths the little extra time to get a good diff and add a little bit of configuration.

We are all extremely busy so if you send it like this it will unfortunately will probably never get integrated.

It seems that you are loosing time to migrate while you could probably move more stuff on the Portal SVN end and then not have to worry about migration.

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 07:20:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Fri, 10 Aug 2007 07:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1742107.1186744801795.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=comments#action_12371715 ] 
            
Antoine Herzog commented on JBPORTAL-1146:
------------------------------------------

ok... understood
use the tools (svn) to make it easy for everybody
I did not think of doing some of my work on my projects as a contribution... from the beginning. 
I will... and organize thing for that

sorry, also, I did not want to make an offense, saying "take this as it is... I don't want to ear about it".

I will make this for this export import feature... when I work again on that part of my project... and have put my svn in place.

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 07:32:01 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 07:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-141)
 IType.getCompilationUnit() can be
 null if handler class is in jar, leads to event loop exception
Message-ID: <31471639.1186745521420.JavaMail.jira@cloud.prod.atl2.jboss.com>

IType.getCompilationUnit() can be null if handler class is in jar, leads to event loop exception
------------------------------------------------------------------------------------------------

                 Key: GPD-141
                 URL: http://jira.jboss.com/jira/browse/GPD-141
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: Eclipse 3.2 on Windows 2000
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


Following part of my processdefinition.xml:
		<event type="node-leave">
			<action class="x.y.z.MyClass" name="An Action">
				<arg>
					anArg
				</arg>
			</action>
		</event>

MyClass is in a jar which is added to the classpath of the Process Project. Saving throws an event loop exception in Error Log View with the following stack.

Caused by: org.eclipse.jface.util.Assert$AssertionFailedException: null argument;
at org.eclipse.jface.util.Assert.isNotNull(Assert.java:150)
at org.eclipse.jface.util.Assert.isNotNull(Assert.java:126)
at org.eclipse.jface.viewers.StructuredViewer.assertElementsNotNull(StructuredViewer.java:577)
at org.eclipse.jface.viewers.CheckboxTreeViewer.setCheckedElements(CheckboxTreeViewer.java:431)
at org.jbpm.gd.jpdl.deployment.IncludeInDeploymentTreeViewer.setCheckedElements(IncludeInDeploymentTreeViewer.java:61)
at org.jbpm.gd.jpdl.deployment.DeploymentForm$17.run(DeploymentForm.java:635)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123)

The problem is, that DeploymentForm.getElementsToCheckFor() does not respect that MyClass returns null for getCompilationUnit(). As a consequence, setCheckedElements is called with null in the Object[].

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:36:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Aug 2007 08:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1036) config-type schema
 declaration doesnt accept custom instantiator classes
In-Reply-To: <1713438.1186735981810.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12102869.1186749378957.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1036?page=comments#action_12371723 ] 
            
Ronald van Kuijk commented on JBPM-1036:
----------------------------------------

3.1 schema also had this restriction. most likely you did not have a reference to a schema in pre 3.2 processdefinitions. If you remove de schemareference it will most likely work. So reduced to minor since there is a 'workaround' 

> config-type schema declaration doesnt accept custom instantiator classes
> ------------------------------------------------------------------------
>
>                 Key: JBPM-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1036
>             Project: JBoss jBPM
>          Issue Type: Bug
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: Roland Huss
>         Assigned To: Tom Baeyens
>
> Specifying a custom delegation instantiator with a  fully qualified class name like in
> <action config-type="com.consol.cmas.workflow.jbpm.exe.SpringInstantiator"
>               class="com.consol.cmas.projects.it.workflow.development.AssignCallToReviewerActionHandler"/>
> 	
> doesnt work anymore because the schema allows value from a fixed enumeration only:
> <xs:attribute name="config-type" default="field">
>         <xs:simpleType>
>           <xs:restriction base="xs:string">
>             <xs:enumeration value="field"/>
>             <xs:enumeration value="bean"/>
>             <xs:enumeration value="constructor"/>
>             <xs:enumeration value="configuration-property"/>
>           </xs:restriction>
>         </xs:simpleType>
>  </xs:attribute>
> This contrary to  the relevant code in the Delegation class this should work (and indeed worked in some pre 3.2.1 versions):
> Instantiator instantiator = null;
>     try {
>       // find the instantiator
>       instantiator = (Instantiator) instantiatorCache.get(configType);
>       if (instantiator == null) {
>         // load the instantiator class
>         Class instantiatorClass = classLoader.loadClass(configType);
>         // instantiate the instantiator with the default constructor
>         instantiator = (Instantiator) instantiatorClass.newInstance();
>         instantiatorCache.put(configType, instantiator);
>       }
>     } catch (Exception e) {
>       log.error(e);
>       throw new JbpmException("couldn't instantiate custom instantiator '" + configType + "'", e);
>     }
> 	
> So please either relax the schema restriction (which I highly prefer, since I rely on using a custom instantiator) or remove the possibility to 
> use a custom instantiator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:36:19 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Aug 2007 08:36:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1036) config-type schema
 declaration doesnt accept custom instantiator classes
In-Reply-To: <1713438.1186735981810.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3510148.1186749379267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1036?page=all ]

Ronald van Kuijk updated JBPM-1036:
-----------------------------------

                Issue Type: Feature Request  (was: Bug)
    Workaround Description: remove schema reference in the top of the PD.
                  Priority: Minor  (was: Major)

Oh.. and it is not a bug then, but a feature request. 

> config-type schema declaration doesnt accept custom instantiator classes
> ------------------------------------------------------------------------
>
>                 Key: JBPM-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1036
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: Roland Huss
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> Specifying a custom delegation instantiator with a  fully qualified class name like in
> <action config-type="com.consol.cmas.workflow.jbpm.exe.SpringInstantiator"
>               class="com.consol.cmas.projects.it.workflow.development.AssignCallToReviewerActionHandler"/>
> 	
> doesnt work anymore because the schema allows value from a fixed enumeration only:
> <xs:attribute name="config-type" default="field">
>         <xs:simpleType>
>           <xs:restriction base="xs:string">
>             <xs:enumeration value="field"/>
>             <xs:enumeration value="bean"/>
>             <xs:enumeration value="constructor"/>
>             <xs:enumeration value="configuration-property"/>
>           </xs:restriction>
>         </xs:simpleType>
>  </xs:attribute>
> This contrary to  the relevant code in the Delegation class this should work (and indeed worked in some pre 3.2.1 versions):
> Instantiator instantiator = null;
>     try {
>       // find the instantiator
>       instantiator = (Instantiator) instantiatorCache.get(configType);
>       if (instantiator == null) {
>         // load the instantiator class
>         Class instantiatorClass = classLoader.loadClass(configType);
>         // instantiate the instantiator with the default constructor
>         instantiator = (Instantiator) instantiatorClass.newInstance();
>         instantiatorCache.put(configType, instantiator);
>       }
>     } catch (Exception e) {
>       log.error(e);
>       throw new JbpmException("couldn't instantiate custom instantiator '" + configType + "'", e);
>     }
> 	
> So please either relax the schema restriction (which I highly prefer, since I rely on using a custom instantiator) or remove the possibility to 
> use a custom instantiator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:57:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1626) FIrst access to
 a CMS HTML file through /content/ results in a NPE
Message-ID: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>

FIrst access to a CMS HTML file through /content/ results in a NPE
------------------------------------------------------------------

                 Key: JBPORTAL-1626
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.6.1 Final
            Reporter: Thomas Heute
         Assigned To: Sohil Shah
             Fix For: 2.6.2 Final


To reproduce, after startup go to:
http://localhost:8080/portal/content/default/project.html

It will fails to acquire a read lock resulting in a null content.

It fails when trying to do:
             VersionHistory vh = contentNode.getVersionHistory();

in ContentGetCommand


On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:59:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 08:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5753497.1186750741317.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12371726 ] 
            
Thomas Heute commented on JBPORTAL-1626:
----------------------------------------

By the way it was working fine on 2.6.0.

I had a quick look at the diff between the 2 in cms and core-cms but couldn't spot anything obvious.

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 09:14:27 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 09:14:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
Message-ID: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jbpm.gd.common.properties should be exported in MANIFEST:MF
---------------------------------------------------------------

                 Key: GPD-142
                 URL: http://jira.jboss.com/jira/browse/GPD-142
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 09:26:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 09:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8415180.1186752361617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-142?page=comments#action_12371732 ] 
            
Koen Aers commented on GPD-142:
-------------------------------

This is part of a refactoring that will happen later. 

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 09:48:00 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 10 Aug 2007 09:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1627) Problem
 destroying service
 portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
Message-ID: <12607797.1186753680992.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1627
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1627
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Widget
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
            Priority: Minor
             Fix For: 2.6.2 Final


On AS shutdown:

Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
java.lang.reflect.UndeclaredThrowableException
        at $Proxy0.destroy(Unknown Source)
        at org.jboss.system.ServiceController.destroy(ServiceController.java:577)
        at org.jboss.system.ServiceController.shutdown(ServiceController.java:714)
        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.server.ServerImpl$ShutdownHook.shutdownServices(ServerImpl.java:1079)
        at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1037)
        at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
Caused by: javax.management.InstanceNotFoundException: portal:service=ContentRenderer,type=GoogleWidgetPortletInstance is not registered.
        at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:653)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
        ... 15 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 lists.jboss.org  Fri Aug 10 09:58:56 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 10 Aug 2007 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4601) Add example
 sybase-xa-ds.xml from the forums
Message-ID: <24810986.1186754336899.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add example sybase-xa-ds.xml from the forums
--------------------------------------------

                 Key: JBAS-4601
                 URL: http://jira.jboss.com/jira/browse/JBAS-4601
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JCA service
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


Add the example sybase xa configuration to docs/examples/jca

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:02:01 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 10 Aug 2007 10:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1037) process image
 rendered incorrectly for large process definition
Message-ID: <2916967.1186754521287.JavaMail.jira@cloud.prod.atl2.jboss.com>

process image rendered incorrectly for large process definition
---------------------------------------------------------------

                 Key: JBPM-1037
                 URL: http://jira.jboss.com/jira/browse/JBPM-1037
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Web Interface
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: mac osx,  tomcat 5.0.28
            Reporter: Ross McDonald
         Assigned To: Tom Baeyens
            Priority: Minor


Hi,

then I create a large process, and extend to the left beyond the original boundary, by placing and element in the designer and dragging, so scrollbars appear, the image when rendered in the console is offset incorrectly while on any given node,

cheers

Ross

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:02:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 10 Aug 2007 10:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4601) Add example
 sybase-xa-ds.xml from the forums
In-Reply-To: <24810986.1186754336899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23019700.1186754521416.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Adrian Brock closed JBAS-4601.
------------------------------

    Resolution: Done

> Add example sybase-xa-ds.xml from the forums
> --------------------------------------------
>
>                 Key: JBAS-4601
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4601
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> Add the example sybase xa configuration to docs/examples/jca

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:08:01 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 10 Aug 2007 10:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1037) process image
 rendered incorrectly for large process definition
In-Reply-To: <2916967.1186754521287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16990792.1186754881467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1037?page=all ]

Ross McDonald updated JBPM-1037:
--------------------------------

    Workaround Description: don't move any element in the designer beyond the original left margin

> process image rendered incorrectly for large process definition
> ---------------------------------------------------------------
>
>                 Key: JBPM-1037
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1037
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: mac osx,  tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> Hi,
> then I create a large process, and extend to the left beyond the original boundary, by placing and element in the designer and dragging, so scrollbars appear, the image when rendered in the console is offset incorrectly while on any given node,
> cheers
> Ross

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:30:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1577) Adding a window
 is not reflected immediately
In-Reply-To: <25157575.1184332923806.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6864318.1186756201440.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1577.
------------------------------------

    Resolution: Rejected

There is no way to do it so that:
- It's efficient
- Doesn't require lot of changes

This issue doesn't exist in 2.6 Branch (after lot of changes)

> Adding a window is not reflected immediately
> --------------------------------------------
>
>                 Key: JBPORTAL-1577
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1577
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.4.2 Final
>
>         Attachments: PageNavigationInterceptor.patch
>
>
> org.jboss.portal.core.aspects.controller.PagaNavigationIntercepor is caching the window context map of a page.
> The side effect is that if you dynamically add a window, you need to start a new session to see the change.
> (That issue is not 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 lists.jboss.org  Fri Aug 10 10:32:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1231) Management
 beans initialized too many times
In-Reply-To: <12447684.1170670759570.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25998596.1186756322066.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1231.
------------------------------------

    Fix Version/s:     (was: 2.4.3 Final)
       Resolution: Won't Fix

> Management beans initialized too many times
> -------------------------------------------
>
>                 Key: JBPORTAL-1231
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1231
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1, 2.6.Alpha2
>         Environment: AS 4.0.5
> Portal 2.6Alpha1 or Alpha2 from svn tag
>            Reporter: Ryszard Kozmik
>         Assigned To: Julien Viet
>            Priority: Minor
>
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'portalobjectmgr' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'portalAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'addPageAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'addWindowAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'themePropertyAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'instancemgr' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'preferenceAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'portletmgr' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'createInstanceAction' - only keeping the 
> Those warnings are harmless and are caused by newer myfaces libraries in AS 4.0.5. Please look at forum link included in this task for sollution. However, this sollution might not fully work as Portal has quite old Facelets libraries.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:51:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1611)
 ActionRequest.sendRedirect() doesn't work
In-Reply-To: <14641528.1185385247142.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <430091.1186757461387.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1611.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

> ActionRequest.sendRedirect() doesn't work
> -----------------------------------------
>
>                 Key: JBPORTAL-1611
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1611
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> sendRedirect() doesn't work anymore on an actionRequest.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:53:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1612) Let the user
 specify a redirection on the signout URL mapping
In-Reply-To: <23128939.1185385374886.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29245726.1186757582810.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1612.
------------------------------------

    Resolution: Done

> Let the user specify a redirection on the signout URL mapping
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1612
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1612
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:59:15 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:59:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1590)
 org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager trace
 log action prints permission type
In-Reply-To: <22703648.1184661407170.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17974515.1186757955550.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1590.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

> org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager trace log action prints permission type
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1590
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1590
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.6 Final
>            Reporter: Juergen none
>         Assigned To: Thomas Heute
>            Priority: Trivial
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager::checkPermission() trace log prints permission.getType() for action
> should probably be permission.getName() ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:07:02 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 10 Aug 2007 11:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4600) Rename JBossMQ
 variables from
 jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into
 build-thirdparty
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6475663.1186758422564.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBAS-4600.
---------------------------------

    Resolution: Done

> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:21:29 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 11:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29717368.1186759289656.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-142?page=comments#action_12371747 ] 
            
Koen Aers commented on GPD-142:
-------------------------------

oh, i did not see the title... i will do this rightaway

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 11:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10420391.1186759381047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-142?page=all ]

Koen Aers closed GPD-142.
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:31:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 11:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-111) Add ability to forward
 and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16155815.1186759861233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Koen Aers updated GPD-111:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
                       (was: jBPM JPDL Designer 3.1.0.CR)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:38:36 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <823047.1186760316698.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-142?page=comments#action_12371749 ] 
            
Matthias Hanisch commented on GPD-142:
--------------------------------------

Thanks. Another diff is gone :).

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:54:13 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 11:54:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-143) Load the icon of a
 paletteContribution entry from the plugin directory where it is defined
Message-ID: <28132773.1186761253835.JavaMail.jira@cloud.prod.atl2.jboss.com>

Load the icon of a paletteContribution entry from the plugin directory where it is defined
------------------------------------------------------------------------------------------

                 Key: GPD-143
                 URL: http://jira.jboss.com/jira/browse/GPD-143
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


In PaletteRoot class, the icon of a palette entry is always loaded from org.jbpm.gd.jpdl plugin, even if the paletteContribution entry is defined in a dependent plugin.
The information, where the palette entry element (entryElement in PaletteRoot.addControls) is defined, can be found in entryElement.getContributor().getName().
So also the corresponding image can be loaded from the correct bundle.

[ Sorry to only give a verbal description of the implementation. I would sign a corporate contributor's agreement, but I have problems with the procedure, e.g.
- do we need a corporate jboss account for my boss to sign
- if we sign with the "corporate" account, with which account I need to contribute then
etc.
So I would need some assistance here. Then you would get a real diff also.
]


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:56:03 2007
From: jira-events at lists.jboss.org (=?UTF-8?Q?Roland_R=C3=A4z_=28JIRA=29?=)
Date: Fri, 10 Aug 2007 11:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4602)
 org.jboss.deployment.DeploymentException is thrown when configuring the
 ServerSocketFactory attribute of the NamingService
Message-ID: <19579224.1186761363641.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.deployment.DeploymentException is thrown when configuring the ServerSocketFactory attribute of the NamingService
--------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4602
                 URL: http://jira.jboss.com/jira/browse/JBAS-4602
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Roland R?z


The following exception is thrown when the ServerSocketFactory attribute is configured in the org.jboss.naming.NamingService MBean is configured:

16:09:01,948 INFO  [ServiceConfigurator] Problem configuring service jboss:service=Naming
org.jboss.deployment.DeploymentException: No property editor for attribute: ServerSocketFactory; type=interface java.rmi.server.RMIServerSocketFactory
        at org.jboss.system.ServiceConfigurator.parseTextSerialData(ServiceConfigurator.java:554)
        at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:329)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
        at org.jboss.system.ServiceController.install(ServiceController.java:226)
        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)
...


Reason:

The file conf/xmdesc/NamingService-xmbean.xml contains a second definition of the ServerSocketFactory attribute ServerSocketFactory. The second definition should be ServerSocketFactoryBean.

Snippet from NamingService-xmbean.xml:

<attribute access="read-write" getMethod="getServerSocketFactory" setMethod="setServerSocketFactory">
 <description>The RMI service java.rmi.server.RMIServerSocketFactory class name</description>
 <name>ServerSocketFactory</name>
 <type>java.lang.String</type>
</attribute>
<attribute access="read-write" getMethod="getServerSocketFactoryBean" setMethod="setServerSocketFactoryBean">
 <description>The RMI service java.rmi.server.RMIServerSocketFactory instance</description>
 <name>ServerSocketFactory</name>
 <type>java.rmi.server.RMIServerSocketFactory</type>
</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 lists.jboss.org  Fri Aug 10 11:58:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 10 Aug 2007 11:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-105) switch from oswego to
 java.util concurrent
Message-ID: <23612134.1186761481061.JavaMail.jira@cloud.prod.atl2.jboss.com>

switch from oswego to java.util concurrent
------------------------------------------

                 Key: JBXB-105
                 URL: http://jira.jboss.com/jira/browse/JBXB-105
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Task
    Affects Versions:  JBossXB-2.0.0.CR2, JBossXB-1.0.0.CR10
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky
             Fix For: JBossXB-1.0.0.CR11, JBossXB-2.0.0.CR3


It was decided to move away from the oswego to java.util concurrent package, make XB build with Java5 compiler and use retroweaver if java1.4 binary compliance 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 lists.jboss.org  Fri Aug 10 12:07:01 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 10 Aug 2007 12:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-105) GossipRouter should
 additionally listen on IP multicast group and bridge traffic
Message-ID: <539632.1186762021339.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-105?page=comments#action_12371759 ] 
            
Galder Zamarreno commented on JGRP-105:
---------------------------------------

Looking at JBCACHE-816, I spotted some potential requirements 
for JGRP-105 as explained in:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4073104#4073104

Note: DC refers to Data Centre as indicated in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheAcrossDataCentres

Summarised requirements:

- be able to filter which traffic get's propagated to DCs, i.e. only JBC 
CRUD methods (put, remove...etc). JGroups could define an interface 
for that, which JBC would implement based on its requirements.

- configurable (sync/async) communications for in DC (typically IP multicast and 
synchronous) and inter DC (inter GR - typically TCP based and asynchronous)

- GR failover. We need to support failover of a GR so that another node in the 
local DC takes over. 

> GossipRouter should additionally listen on IP multicast group and bridge traffic
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-105
>                 URL: http://jira.jboss.com/jira/browse/JGRP-105
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> GossipRouter should be augmented to not just route traffic between TCP endpoints, but also between an IP multicast group and all TCP endpoints.
> It should be configured with the properties for a (multicast-based) group X, and then forward messages from X to all of its attached endpoints, and vice versa.
> In the future, this concept could be extended to generic bridging functionality, which will allow to construct hierarchical messaging trees, similar to the MBone

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 12:12:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 10 Aug 2007 12:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-105) switch from oswego to
 java.util concurrent
In-Reply-To: <23612134.1186761481061.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24917355.1186762321079.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Alexey Loubyansky closed JBXB-105.
----------------------------------

    Resolution: Done

Done.

> switch from oswego to java.util concurrent
> ------------------------------------------
>
>                 Key: JBXB-105
>                 URL: http://jira.jboss.com/jira/browse/JBXB-105
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-1.0.0.CR10,  JBossXB-2.0.0.CR2
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR11, JBossXB-2.0.0.CR3
>
>
> It was decided to move away from the oswego to java.util concurrent package, make XB build with Java5 compiler and use retroweaver if java1.4 binary compliance 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 lists.jboss.org  Fri Aug 10 12:30:01 2007
From: jira-events at lists.jboss.org (Jaya prakash (JIRA))
Date: Fri, 10 Aug 2007 12:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4603) How to Find out
 client login time,logout time and what he did in JBoss log
Message-ID: <27906119.1186763401140.JavaMail.jira@cloud.prod.atl2.jboss.com>

How to Find out client login time,logout time and what he did in JBoss log
--------------------------------------------------------------------------

                 Key: JBAS-4603
                 URL: http://jira.jboss.com/jira/browse/JBAS-4603
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Jaya prakash
            Priority: Blocker


Here i am facing the issue to find out the user(client) log-in time and log-out time, If he done any thing what he done. I searched in log file but i didn't find out that clearly .

Please advise me.

Regards,
Red 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 12:46:08 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Fri, 10 Aug 2007 12:46:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14612950.1186764368765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371763 ] 
            
John Ruud commented on GPD-128:
-------------------------------

Koen,

I used to add a child element to a SemanticElement by passing in the element-name of the child. Looking at this again I suspect I should just use parentNode.getFactory().createById(), passing in the element id instead, right? (not sure why I didn't do this in the first place)

Thanks, John

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Fri Aug 10 13:49:01 2007
From: jira-events at lists.jboss.org (Steven Holmes (JIRA))
Date: Fri, 10 Aug 2007 13:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-253) Throwing an
 exception when adding a category or forum on 2.6.1 and 4.2
Message-ID: <33225614.1186768141443.JavaMail.jira@cloud.prod.atl2.jboss.com>

Throwing an exception when adding a category or forum on 2.6.1 and 4.2
----------------------------------------------------------------------

                 Key: JBFORUMS-253
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-253
             Project: JBoss Forums
          Issue Type: Bug
          Components: Forum View Layer
    Affects Versions: 1.0.0 GA
         Environment: 2.6.1 on 4.2 on Windows XP Pro
            Reporter: Steven Holmes
         Assigned To: Ryszard Kozmik


It is throwing a funny exception whenever I add a category or forum in admin mode.  The exception appears to be the same regardless of whether I am adding a forum or category.
I got the following exception when I was trying to add my first Category:

ERROR
Cause: javax.portlet.PortletException: javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
Message: javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
StackTrace:

javax.portlet.PortletException: javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:367)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:397)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(TransactionInterceptor.java:106)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeRequired(TransactionInterceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:80)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
	at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
	at sun.reflect.GeneratedMethodAccessor353.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:99)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
	at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
	at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
	at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
	at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:116)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
	at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
	at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
	at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
	at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
	at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
	at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
	at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
	at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
	at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:595)
javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:254)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:400)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:363)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:397)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(TransactionInterceptor.java:106)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeRequired(TransactionInterceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:80)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
	at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
	at sun.reflect.GeneratedMethodAccessor353.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:99)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
	at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
	at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
	at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
	at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:116)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
	at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
	at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
	at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
	at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
	at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
	at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
	at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
	at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
	at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:595)
java.lang.IllegalStateException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
	at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:241)
	at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
	at org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:204)
	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:554)
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:352)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:396)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:363)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:397)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(TransactionInterceptor.java:106)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeRequired(TransactionInterceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:80)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
	at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
	at sun.reflect.GeneratedMethodAccessor353.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:99)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
	at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
	at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
	at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
	at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:116)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
	at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
	at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
	at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
	at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
	at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
	at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
	at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
	at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
	at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	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 lists.jboss.org  Fri Aug 10 14:34:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Fri, 10 Aug 2007 14:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-472) Release JBoss Cache
	2.0
Message-ID: <15978620.1186770841216.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Manik Surtani closed JBCACHE-472.
---------------------------------

    Resolution: Done

> Release JBoss Cache 2.0
> -----------------------
>
>                 Key: JBCACHE-472
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-472
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Ryan Campbell
>             Fix For: 2.0.0.GA
>
>
> Add all release tasks here (docos, tutorials, dr through to rc, 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 lists.jboss.org  Fri Aug 10 14:40:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 10 Aug 2007 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1031) Potential
 bug in cancelling delivery
In-Reply-To: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25037834.1186771201149.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic reassigned JBMESSAGING-1031:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Potential bug in cancelling delivery
> ------------------------------------
>
>                 Key: JBMESSAGING-1031
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 16:32:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Aug 2007 16:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1044) Cleanup docs
 using xml editor
In-Reply-To: <5895634.1186684741257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12467704.1186777921081.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-1044:
---------------------------------

    Fix Version/s: 1.4.0.GA
                       (was: 1.4.0.CR2)

> Cleanup docs using xml editor
> -----------------------------
>
>                 Key: JBMESSAGING-1044
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1044
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 17:00:01 2007
From: jira-events at lists.jboss.org (Przemyslaw Dej (JIRA))
Date: Fri, 10 Aug 2007 17:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-250) Posts created by
 Anonymous user cause problems.
In-Reply-To: <8514775.1184854073939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24836000.1186779601417.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Przemyslaw Dej resolved JBFORUMS-250.
-------------------------------------

    Resolution: Done

> Posts created by Anonymous user cause problems.
> -----------------------------------------------
>
>                 Key: JBFORUMS-250
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-250
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Forum View Layer, Forum Model Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Przemyslaw Dej
>             Fix For: 1.0.1 RC
>
>          Time Spent: 3 days
>
> Please read forum reference for more information about the 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 lists.jboss.org  Fri Aug 10 20:09:19 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 10 Aug 2007 20:09:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-322) Allow the
 conversion of normal Java projects to Drools projects
Message-ID: <30533971.1186790959692.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen updated JBRULES-322:
-----------------------------------

    Fix Version/s: 4.0.1
                       (was: 3.1-m1)

Added a better implementation, you can now just right-click the (Java)Project and execute the Convert action.
Also first checks whether the necessary elements are already added or not.

> Allow the conversion of normal Java projects to Drools projects
> ---------------------------------------------------------------
>
>                 Key: JBRULES-322
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-322
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.1
>            Reporter: Kris Verlaenen
>         Assigned To: Kris Verlaenen
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Allow the conversion of normal Java projects to Drools projects, preferable as a menu item when right-clicking a (non-drools Java) 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 lists.jboss.org  Fri Aug 10 21:18:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1068) Exception when
 adding
 "activation-group" attribute to otherwise correctly executed rule...
In-Reply-To: <25370522.1186685101163.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11523833.1186795081403.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

there should be no = on activation group. Although the error feedback is not good.
activation-group "unique-solution"

> Exception when adding "activation-group" attribute to otherwise correctly executed rule...
> ------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1068
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1068
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> rule "Golfer-Riddle with a single solution?" 
> 	activation-group="unique-solution"
>     when
>         // There is a golfer names Fred, 
>         $f: Golfer( name == "Fred",
> ...
> yields:
> Exception in thread "main" org.drools.compiler.DroolsParserException: Unknown error while parsing. This is a bug. Please contact the Development team.
> 	at org.drools.compiler.DrlParser.compile(DrlParser.java:180)
> 	at org.drools.compiler.DrlParser.parse(DrlParser.java:61)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:19)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:18:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1068) Better error
 handling for incorrect chars with rule attributes
In-Reply-To: <25370522.1186685101163.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21093645.1186795081613.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1068:
----------------------------------

          Summary: Better error handling for incorrect chars with rule attributes  (was: Exception when adding "activation-group" attribute to otherwise correctly executed rule...)
    Fix Version/s: FUTURE

> Better error handling for incorrect chars with rule attributes
> --------------------------------------------------------------
>
>                 Key: JBRULES-1068
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1068
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> rule "Golfer-Riddle with a single solution?" 
> 	activation-group="unique-solution"
>     when
>         // There is a golfer names Fred, 
>         $f: Golfer( name == "Fred",
> ...
> yields:
> Exception in thread "main" org.drools.compiler.DroolsParserException: Unknown error while parsing. This is a bug. Please contact the Development team.
> 	at org.drools.compiler.DrlParser.compile(DrlParser.java:180)
> 	at org.drools.compiler.DrlParser.parse(DrlParser.java:61)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:19)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:20:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
In-Reply-To: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20820214.1186795201222.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1070:
----------------------------------

    Fix Version/s: 4.0.1

> Exception with "not in" condition with  (int-values)
> ----------------------------------------------------
>
>                 Key: JBRULES-1070
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> // Bob wears plaid       
> Golfer( name == "Bob", 
>         $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
>         $bobsColor : color == "plaid",
>         color != $fredsColor, color != $joesColor,
>         color != $fredsNeighbourColor )
> yields the following exception
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
> 	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:22:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
In-Reply-To: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4448230.1186795321407.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

There has been a url change and infrastructure have not got redirects working yet :( If you go to the main drools home page now and navigate to the docs page you'll see it does have the correct docs:
http://labs.jboss.com/drools/docs/index.html

the build.xml files no longer exist as we are totally mavenised now.

> Installation / Build instructions do not match what SVN delivers
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1072
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP on Dell desktop
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>
> Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.
> There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.
> Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
> C:\dev\jbossrules\drools-eclipse>ant clean-all
> Buildfile: build.xml
> BUILD FAILED
> Target "clean-all" does not exist in the project "Build All Elements".
> Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
> eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.
> Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:22:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
In-Reply-To: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8469151.1186795321589.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1072.
---------------------------------

    Resolution: Won't Fix

There isn't anything I can do here, have to wait for IT to setup redirects.

> Installation / Build instructions do not match what SVN delivers
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1072
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP on Dell desktop
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>
> Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.
> There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.
> Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
> C:\dev\jbossrules\drools-eclipse>ant clean-all
> Buildfile: build.xml
> BUILD FAILED
> Target "clean-all" does not exist in the project "Build All Elements".
> Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
> eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.
> Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 05:15:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sat, 11 Aug 2007 05:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23779107.1186823701113.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371789 ] 
            
Koen Aers commented on GPD-128:
-------------------------------

Yes that is correct. 

Don't worry, I regularly make similar mistakes ;-)

Cheers,
Koen

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sat Aug 11 12:46:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 11 Aug 2007 12:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5205841.1186850761659.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I'm not seeing this with code in trunk. I changed the iteration in "run" from 3 to 20 and asked it to do 200 packages and go the following output:
Added 200 packages to rulebase1 in 0.375 seconds
Added 200 packages to rulebase2 in 0.141 seconds
Added 200 packages to rulebase3 in 0.125 seconds
Added 200 packages to rulebase4 in 0.172 seconds
Added 200 packages to rulebase5 in 0.125 seconds
Added 200 packages to rulebase6 in 0.125 seconds
Added 200 packages to rulebase7 in 0.125 seconds
Added 200 packages to rulebase8 in 0.156 seconds
Added 200 packages to rulebase9 in 0.172 seconds
Added 200 packages to rulebase10 in 0.109 seconds
Added 200 packages to rulebase11 in 0.109 seconds
Added 200 packages to rulebase12 in 0.125 seconds
Added 200 packages to rulebase13 in 0.11 seconds
Added 200 packages to rulebase14 in 0.109 seconds
Added 200 packages to rulebase15 in 0.125 seconds
Added 200 packages to rulebase16 in 0.219 seconds
Added 200 packages to rulebase17 in 0.094 seconds
Added 200 packages to rulebase18 in 0.125 seconds
Added 200 packages to rulebase19 in 0.109 seconds
Added 200 packages to rulebase20 in 0.109 seconds

Is there something I'm not getting, or not running the test correctly?
Bits I changed are:
    public void run() throws Exception {
        List drls = generateDrls();
        List pkgs = generatePackages( drls );

        for ( int i = 0; i < 20; i++ ) {
            addPackages( pkgs,
                         i + 1 );
        }
    }


    public static void main(String[] argv) throws Exception {
        if ( argv.length > 0 ) {
            try {
                new TestDrools( Integer.parseInt( argv[0] ) ).run();
            } catch ( Exception ex ) {
                ex.printStackTrace();
            }
        } else { //System.out.println( "Usage: TestDrool [# of packages]" );
            new TestDrools( 200 ).run();
        }
    }

If I am running the test correctly and my results are ok,  can I please ask you to test trunk using the snapshot builds here:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sat Aug 11 12:56:03 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 12:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27691797.1186851363330.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1060:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Sat Aug 11 13:34:05 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 11 Aug 2007 13:34:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1059) Online typos in
	Section 1
In-Reply-To: <15111425.1186340029389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14798915.1186853645306.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1059.
---------------------------------

    Resolution: Done

> Online typos in Section 1
> -------------------------
>
>                 Key: JBRULES-1059
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1059
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: n/a  - concerns documentation availble for viewing over internet
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> miscellaneous typos
> http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/index.html
> Section 1.1
> modiied ? modified
> Drools will adding ? Drools will be adding
> Section 1.2.1
> explination ? explanation
> layed ? laid
> espically ? especially
> knowlegde ? knowledge
> Section 1.2.4
> preceeding ? preceding
> its ? it's
> Section 1.3.1
> shortley ? shortly
> Section 1.3.2
> conjuntive ? conjunctive
> disjuntive ? disjunctive
> Section 1.6.1
> grammer ? grammar
> deployeable ? deployable
> PackagBuilder ? PackageBuilder
> Section 1.6.4.6
> In the shaded box, should 'new List' simply be 'List' ?
> Section 1.6.5
> legible ? eligible
> section 1.6.6.1
> managable ? manageable
> section 1.6.7
> AgendEventListener ? AgendaEventListener

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 14:35:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1073)
 CompositeContextEntry is raising NPE
Message-ID: <15185920.1186857301091.JavaMail.jira@cloud.prod.atl2.jboss.com>

CompositeContextEntry is raising NPE
------------------------------------

                 Key: JBRULES-1073
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1073
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


Stack Trace:

Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromFactHandle(AbstractCompositeRestriction.java:104)
	at org.drools.common.DoubleBetaConstraints.updateFromFactHandle(DoubleBetaConstraints.java:138)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:308)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:850)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:824)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:625)
	at org.drools.examples.GolfingExample.main(GolfingExample.java:32)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 14:37:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 14:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1073)
 CompositeContextEntry is raising NPE
In-Reply-To: <15185920.1186857301091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8993213.1186857421131.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-1073.
------------------------------------

    Resolution: Done

Problem was a mistake in the constructor where an incorrect variable declaration was shadowing the instance attribute:

    public static class CompositeContextEntry
        implements
        ContextEntry {
        public ContextEntry[] contextEntries;

        private ContextEntry  entry;

        public CompositeContextEntry(final Restriction[] restrictions) {
            final ContextEntry[] contextEntries = new ContextEntry[restrictions.length];
            for ( int i = 0; i < restrictions.length; i++ ) {
                contextEntries[i] = restrictions[i].getContextEntry();
            }
        }

Fixed.

> CompositeContextEntry is raising NPE
> ------------------------------------
>
>                 Key: JBRULES-1073
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1073
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Stack Trace:
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromFactHandle(AbstractCompositeRestriction.java:104)
> 	at org.drools.common.DoubleBetaConstraints.updateFromFactHandle(DoubleBetaConstraints.java:138)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:308)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:850)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:824)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:625)
> 	at org.drools.examples.GolfingExample.main(GolfingExample.java:32)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 14:39:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 14:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1073)
 CompositeContextEntry is raising NPE
In-Reply-To: <15185920.1186857301091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19309383.1186857541071.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1073.
----------------------------------


> CompositeContextEntry is raising NPE
> ------------------------------------
>
>                 Key: JBRULES-1073
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1073
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Stack Trace:
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromFactHandle(AbstractCompositeRestriction.java:104)
> 	at org.drools.common.DoubleBetaConstraints.updateFromFactHandle(DoubleBetaConstraints.java:138)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:308)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:850)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:824)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:625)
> 	at org.drools.examples.GolfingExample.main(GolfingExample.java:32)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 15:44:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 15:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3771739.1186861441213.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=comments#action_12371800 ] 
            
Edson Tirelli commented on JBRULES-1056:
----------------------------------------

Mark,

I'm seeing the behavior both on 4.0GA and trunk. Doing a quick profiling, seems the reason is the PackageCompilationData.write() method:

    public void write(final String resourceName,
                      final byte[] clazzData) throws RuntimeDroolsException {
        if ( this.store.put( resourceName,
                             clazzData ) != null ) {
            // we are updating an existing class so reload();
            reload();
        } else {
            try {
                wire( convertResourceToClassName( resourceName ) );
            } catch ( final Exception e ) {
                e.printStackTrace();
                throw new RuntimeDroolsException( e );
            }
        }
    }

    The first time a rule base is loaded, the classes are generated and loaded, but from the second time and on, as the class already exists, the reload() method is called, and it seems to be quite heavy:

    public void reload() throws RuntimeDroolsException {
        // drops the classLoader and adds a new one
        this.classLoader = new PackageClassLoader( this.parentClassLoader );

        // Wire up invokers
        try {
            for ( final Iterator it = this.invokerLookups.keySet().iterator(); it.hasNext(); ) {
                wire( (String) it.next() );
            }
        } catch ( final ClassNotFoundException e ) {
            throw new RuntimeDroolsException( e );
        } catch ( final InstantiationError e ) {
            throw new RuntimeDroolsException( e );
        } catch ( final IllegalAccessException e ) {
            throw new RuntimeDroolsException( e );
        } catch ( final InstantiationException e ) {
            throw new RuntimeDroolsException( e );
        }
    }

    Profiling is charging up to 50% of run time to that method when running that test.

    Seems we need to either make this method lighter or at least check and only reload if the bytecodes actually change....


> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 05:03:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 05:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8527132.1186909381368.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Why didn't it show up in my test results?

Yes due to java issues on the classloader it does a reload() if thet classname already exists.. However that should not have something that gets increasingly worse, maybe a slightly heaver hit the second time, but should be the same for each consecutive time after that. I guess with MVEL in reflection mode this shouldn't be an issue, so that may be a work around from now. If a rule is being reloaded what are the chances the byte[] hasn't changed?

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 05:05:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 05:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7107784.1186909501108.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

just had a thought, if you have 200 classes its going to drop and reload 200 times. However the reload only needs to happen once. So the answer is to some how have a callback so reload only happens at the end, maybe even on the first working memory action....

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 05:54:01 2007
From: jira-events at lists.jboss.org (Lior Ban (JIRA))
Date: Sun, 12 Aug 2007 05:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1025) When running
 HBM2DDL on
 StringInstnace.hbm.xml on oracle DB, the length of the column length is 255
 even that it defined 4000 in hbm
In-Reply-To: <33100434.1185195227128.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16459037.1186912441197.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1025?page=comments#action_12371805 ] 
            
Lior Ban commented on JBPM-1025:
--------------------------------

There is a solution to this, the file StringInstance.hbm.xml can be changed as follow to support this:

<?xml version="1.0"?>

<!DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD 3.0//EN" 
    "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping default-access="field">

  <subclass name="org.jbpm.context.exe.variableinstance.StringInstance" 
            extends="org.jbpm.context.exe.VariableInstance" 
            discriminator-value="S">
    <property name="value" type="string" column="STRINGVALUE_" length="4000"/>
  </subclass>
  
  <database-object>
    <create>
       ALTER TABLE "JBPM_VARIABLEINSTANCE" MODIFY "STRINGVALUE_" varchar(4000)  
    </create>
    <drop></drop>  
    <dialect-scope name="org.hibernate.dialect.SybaseAnywhereDialect"></dialect-scope>
  </database-object>
  
  <database-object>  
    <create>  
       ALTER TABLE jbpm_variableinstance MODIFY COLUMN STRINGVALUE_ VARCHAR(4000)  
    </create>  
    <drop></drop>  
    <dialect-scope name="org.hibernate.dialect.MySQLDialect"></dialect-scope>  
    <dialect-scope name="org.hibernate.dialect.DB2Dialect"></dialect-scope>  
    <dialect-scope name="org.hibernate.dialect.OracleDialect"></dialect-scope>  
  </database-object>

</hibernate-mapping>



> When running HBM2DDL on StringInstnace.hbm.xml on oracle DB, the length of the column length is 255 even that it defined 4000 in hbm
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1025
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1025
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: Oracle on Unix Solaris
>            Reporter: Lior Ban
>         Assigned To: Tom Baeyens
>
> We create the Oracle JBPM DB tables by running Hbm2Ddl,
> In the StringInstance.hbm.xml file it is writen:
> <property name="value" type="string" length="4000">
> However still when creating the DB in the DB explorer we see that it is VARCHAR2(255) length 255
> Maybe it is veacuse setValue and getValue return object in VarilableInstance object from which StringInstance inherits?
> When we have string with length 269 it can't be put in the DB and we get 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 lists.jboss.org  Sun Aug 12 09:23:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1074) Support the use
 of Integer, Float, Short and Byte in accumulate functions
Message-ID: <14718682.1186924981314.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support the use of Integer, Float, Short and Byte in accumulate functions
-------------------------------------------------------------------------

                 Key: JBRULES-1074
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1074
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Edson Tirelli
            Priority: Minor
             Fix For: 4.0.1


Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 10:14:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 10:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1074) Support the use
 of Integer, Float, Short and Byte in accumulate functions
In-Reply-To: <14718682.1186924981314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15676478.1186928041213.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1074?page=comments#action_12371806 ] 
            
Geoffrey De Smet commented on JBRULES-1074:
-------------------------------------------

The value in this signature is always a Long, even if it's an Integer:

public void accumulate(Object context,
                           Object value) {

> Support the use of Integer, Float, Short and Byte in accumulate functions
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1074
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1074
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 10:25:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 10:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1075) Support
 overloading of
 accumulate functions: Add int (or long) based sum's, int based avarage's,
 etc
Message-ID: <28273319.1186928701233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc 
-----------------------------------------------------------------------------------------------------

                 Key: JBRULES-1075
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1075
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Edson Tirelli
            Priority: Minor
             Fix For: FUTURE


TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:

1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.

2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
 sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
 sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.

And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
  sum($myString)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 10:28:06 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 10:28:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1075) Support
 overloading of
 accumulate functions: Add int (or long) based sum's, int based avarage's,
 etc
In-Reply-To: <28273319.1186928701233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9551504.1186928886812.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet updated JBRULES-1075:
--------------------------------------

    Attachment: JBRULES-1075.patch

> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc 
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1075
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1075
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: FUTURE
>
>         Attachments: JBRULES-1075.patch
>
>
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
>  sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
>  sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
>   sum($myString)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 14:12:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 12 Aug 2007 14:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-382) Remove Complex
 Advice Signatures from Classic Mode
In-Reply-To: <23885199.1176740459311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4211957.1186942321253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-382?page=all ]

Stale Pedersen resolved JBAOP-382.
----------------------------------

    Resolution: Done

fix commited. needs revision and a we need to decide if the tests should be removed or moved.

> Remove Complex Advice Signatures from Classic Mode
> --------------------------------------------------
>
>                 Key: JBAOP-382
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-382
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We need to update PerVMAdvice class, to remove the possibility of advices that receive joinpoint arguments (currently, the matching of parameters is not completely functional).
> We will leave the possibility of receiving joinpoint arguments as parameters to the annotated-parameters signature.
> This task also includes moving arg tests to beforeafterArgs package.
> PS: documentation is already stating that only annotated-parameters advice signatures can feature joinpoint arguments as parameters. No need to update documentation here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 14:23:01 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Sun, 12 Aug 2007 14:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
Message-ID: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>

Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
------------------------------------------------------------------------------

                 Key: JBRULES-1076
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.MR3
         Environment: WinXP
            Reporter: Dave Dibble
         Assigned To: Mark Proctor
            Priority: Trivial


Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"

Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:

C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
[INFO] Scanning for projects...
[INFO] -------------------------------------------------------------------------
---
[INFO] Building Maven Default Project
[INFO]    task-segment: [clean, install]
[INFO] -------------------------------------------------------------------------
---
[INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
s from central
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
plugin/2.1.1/maven-clean-plugin-2.1.1.pom
1K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
s/3/maven-plugins-3.pom
6K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
-parent-4.pom
9K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
3K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
plugin/2.1.1/maven-clean-plugin-2.1.1.jar
6K downloaded
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
l, but the build is not using one.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5 seconds
[INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
[INFO] Final Memory: 1M/4M
[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 lists.jboss.org  Sun Aug 12 15:43:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 12 Aug 2007 15:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-200) Make sure the
 batch and sh files work
Message-ID: <26720424.1186947781275.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-200?page=comments#action_12371810 ] 
            
Stale Pedersen commented on JBAOP-200:
--------------------------------------

hm, one problem is that the .sh files are packages with dos encoding. the result is that those files will not run with "./run-load15.sh", and if you try "sh run-load15.sh" it would run, but also give a lot of errors and just die before doing anything.
- tested with 2.0.0alpha5.

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 17:22:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 17:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27646950.1186953721321.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I see the test only does the first part, not the second part of re-adding rules to the same rulebase. I've updated the test as follows:
    public void run() throws Exception {
        List drls = generateDrls();
        List pkgs = generatePackages( drls );

        double time = 0;
        for ( int i = 0; i < 20; i++ ) {            
            time += addPackages( pkgs,
                         RuleBaseFactory.newRuleBase(),
                         i + 1 );
        }
        System.out.println( "average time " + (time/20.0) + " seconds.\n\n" );
        
        time = 0;
        RuleBase rb = RuleBaseFactory.newRuleBase();
        for ( int i = 0; i < 20; i++ ) {            
            time += addPackages( pkgs,
                         rb,
                         i + 1 );
        }                
        System.out.println( "average time " + (time/20.0) + " seconds." );               
    }

    private static double addPackages(List pkgs,
                                        RuleBase rb,
                                        int id) throws Exception {
        double start = System.currentTimeMillis();
        for ( Iterator it = pkgs.iterator(); it.hasNext(); ) {
            Package pkg = (Package) it.next();
            rb.addPackage( pkg );
        }
        double time = (System.currentTimeMillis() - start) / 1000.0;
        System.out.println( "Added " + pkgs.size() + " packages to rulebase" + id + " in " + time + " seconds" );
        return time;
    }

and I get the following time outputs:
Added 200 packages to rulebase1 in 0.219 seconds
Added 200 packages to rulebase2 in 0.125 seconds
Added 200 packages to rulebase3 in 0.14 seconds
Added 200 packages to rulebase4 in 0.141 seconds
Added 200 packages to rulebase5 in 0.125 seconds
Added 200 packages to rulebase6 in 0.109 seconds
Added 200 packages to rulebase7 in 0.125 seconds
Added 200 packages to rulebase8 in 0.156 seconds
Added 200 packages to rulebase9 in 0.172 seconds
Added 200 packages to rulebase10 in 0.11 seconds
Added 200 packages to rulebase11 in 0.093 seconds
Added 200 packages to rulebase12 in 0.125 seconds
Added 200 packages to rulebase13 in 0.11 seconds
Added 200 packages to rulebase14 in 0.109 seconds
Added 200 packages to rulebase15 in 0.125 seconds
Added 200 packages to rulebase16 in 0.203 seconds
Added 200 packages to rulebase17 in 0.094 seconds
Added 200 packages to rulebase18 in 0.109 seconds
Added 200 packages to rulebase19 in 0.109 seconds
Added 200 packages to rulebase20 in 0.125 seconds
average time 0.13119999999999998 seconds.


Added 200 packages to rulebase1 in 0.125 seconds
Added 200 packages to rulebase2 in 0.11 seconds
Added 200 packages to rulebase3 in 0.125 seconds
Added 200 packages to rulebase4 in 0.172 seconds
Added 200 packages to rulebase5 in 0.109 seconds
Added 200 packages to rulebase6 in 0.109 seconds
Added 200 packages to rulebase7 in 0.11 seconds
Added 200 packages to rulebase8 in 0.109 seconds
Added 200 packages to rulebase9 in 0.125 seconds
Added 200 packages to rulebase10 in 0.125 seconds
Added 200 packages to rulebase11 in 0.172 seconds
Added 200 packages to rulebase12 in 0.109 seconds
Added 200 packages to rulebase13 in 0.094 seconds
Added 200 packages to rulebase14 in 0.125 seconds
Added 200 packages to rulebase15 in 0.109 seconds
Added 200 packages to rulebase16 in 0.11 seconds
Added 200 packages to rulebase17 in 0.109 seconds
Added 200 packages to rulebase18 in 0.188 seconds
Added 200 packages to rulebase19 in 0.109 seconds
Added 200 packages to rulebase20 in 0.094 seconds
average time 0.12190000000000001 seconds.

Interestingly I still don't get a difference, what are you guys doing differently?

Anyway the code currently is still inefficient due to the constant reload() call, so I'll fix that anyway and hopefully it will fix the issue that everyone else is getting.

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 21:51:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Sun, 12 Aug 2007 21:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1077) Decision tables
 to have ruleflow-group attribute column
Message-ID: <30015767.1186969861144.JavaMail.jira@cloud.prod.atl2.jboss.com>

Decision tables to have ruleflow-group attribute column
-------------------------------------------------------

                 Key: JBRULES-1077
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1077
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Fernando Meyer
            Priority: Minor
             Fix For: 4.0.1


In decision tables, we can set no-loop attributes (amongst others) by haveing a special keyword in a column (chekc the code for how this is done). Would like to add ruleflow-group to this 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 lists.jboss.org  Sun Aug 12 23:32:12 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 23:32:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26809361.1186975932760.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

new code is in so that the reload() is delayed to the first workingmemoryaction, this should really help situations where you are reloading existing rules. My results also show that standard Package loading is faster too, although not exactly sure why....
Added 200 packages to rulebase1 in 0.031 seconds
Added 200 packages to rulebase2 in 0.016 seconds
Added 200 packages to rulebase3 in 0.016 seconds
Added 200 packages to rulebase4 in 0.016 seconds
Added 200 packages to rulebase5 in 0.0 seconds
Added 200 packages to rulebase6 in 0.016 seconds
Added 200 packages to rulebase7 in 0.0 seconds
Added 200 packages to rulebase8 in 0.031 seconds
Added 200 packages to rulebase9 in 0.0 seconds
Added 200 packages to rulebase10 in 0.0 seconds
Added 200 packages to rulebase11 in 0.0 seconds
Added 200 packages to rulebase12 in 0.015 seconds
Added 200 packages to rulebase13 in 0.0 seconds
Added 200 packages to rulebase14 in 0.0 seconds
Added 200 packages to rulebase15 in 0.016 seconds
Added 200 packages to rulebase16 in 0.0 seconds
Added 200 packages to rulebase17 in 0.0 seconds
Added 200 packages to rulebase18 in 0.0 seconds
Added 200 packages to rulebase19 in 0.0 seconds
Added 200 packages to rulebase20 in 0.0 seconds
average time 0.007850000000000001 seconds.


Added 200 packages to rulebase1 in 0.0 seconds
Added 200 packages to rulebase2 in 0.0 seconds
Added 200 packages to rulebase3 in 0.015 seconds
Added 200 packages to rulebase4 in 0.0 seconds
Added 200 packages to rulebase5 in 0.0 seconds
Added 200 packages to rulebase6 in 0.0 seconds
Added 200 packages to rulebase7 in 0.0 seconds
Added 200 packages to rulebase8 in 0.0 seconds
Added 200 packages to rulebase9 in 0.016 seconds
Added 200 packages to rulebase10 in 0.0 seconds
Added 200 packages to rulebase11 in 0.0 seconds
Added 200 packages to rulebase12 in 0.0 seconds
Added 200 packages to rulebase13 in 0.0 seconds
Added 200 packages to rulebase14 in 0.015 seconds
Added 200 packages to rulebase15 in 0.0 seconds
Added 200 packages to rulebase16 in 0.0 seconds
Added 200 packages to rulebase17 in 0.0 seconds
Added 200 packages to rulebase18 in 0.0 seconds
Added 200 packages to rulebase19 in 0.016 seconds
Added 200 packages to rulebase20 in 0.0 seconds
average time 0.0031 seconds.

Anyway its looking good I think. please try out the snapshot build and make sure this works for both of you.

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 23:35:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 23:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29200891.1186976101116.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1056:
----------------------------------

    Attachment: TestDrools.java
                TestObject.java

Just uploading the files I used to test it with.

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: TestDrools.java, testdrools.zip, TestObject.java
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Mon Aug 13 01:15:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 13 Aug 2007 01:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13062392.1186982101202.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1027?page=comments#action_12371820 ] 
            
Michael Neale commented on JBRULES-1027:
----------------------------------------

Yes I think the fix was in MVEL since this bug was raised, shoudl be all cool now. Was certainly an MVEL not a rule grammar problem. 

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 05:20:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 05:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6577034.1186996801090.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371826 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Matthew,

This is not a good way of implementing it. The adapters *have* to be created in the 'createAdapter' method per the specification of the AbstractAdapterFactory class. I will try to come up with an alternative solution.

Regards,
Koen

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 06:09:15 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 06:09:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22223202.1186999755707.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371831 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Hm, this looks indeed like a problem. Doing it before the createAdapter method is called looks like the only solution. I have modified your fix slightly so that the createAdapter method is nevertheless called again after the creation of the adapter. Let me know if it works.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 06:19:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 13 Aug 2007 06:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-20) Address translation in
 transport (NAT support)
Message-ID: <610892.1187000341308.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-20:
-------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

May not be needed anymore, together with logical addresses

> Address translation in transport (NAT support)
> ----------------------------------------------
>
>                 Key: JGRP-20
>                 URL: http://jira.jboss.com/jira/browse/JGRP-20
>             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
>
> On multi-homed systems, the identity of a member is bound to a NIC (either chosen by the OS, or by the
> user through bind_addr): Address. When a message is sent, the msg contains this address as the sender's
> address. Responses go to the same address.
> However, if that NIC breaks, and the sender's OS chooses a different NIC for the datagram packets, the
> receiver will still send the response back to the old address (the identity of the sender cannot
> change).
> If we set the sender's address in any Message on *reception* of the message, we would be able to send
> the response back to a valid NIC in the above case. However, this means the *identity* of the sender
> changes, which JGroups cannot handle.
> SOLUTION I: we could introduce a logical address, which contains the physical address of the NIC
> through which it was sent. Problem: a lot of code would have to change.
> SOLUTION II: we maintain, in each transport, a table of sender's address as defined in the Message, and
> physical address of the {Datagram,Multicast}Packet received. Whenever we send a unicast message, we get
> the destination address from this table through a lookup in which dest_msg.dest_addr is the key.
> We need to reap the table every now and then to purge old addresses, we could use view changes to do
> so.
> Example for SOLUTION II:
> - Member P: address=1.2.3.4:5555
> - P's box has 2 NICs: 1.2.3.4 and 5.6.7.8
> - Receiver R receives a message from P: P.src_addr=1.2.3.4:5555, datagram's address is 1234:5555
> - R doesn't add an entry to the translation table, because the addresses are the same
> - R sends a response: it looks up 1.2.3.4:5555 (dst) in the translation table
> - There is no entry, therefore R sends the response to 1.2.3.4:5555
> - P's NIC 1.2.3.4 is unplugged
> - P sends a message through NIC 5.6.7.8
> - R receives a message M.src_addr=1.2.3.4:5555, datagram's address is 5.6.7.8:5555
> - R adds an entry to its translation table: 1.2.3.4:5555 --> 5.6.7.8:5555
> - R sends a response to 1.2.3.4:5555, since there is an entry for 1.2.3.4:5555, it uses 5.6.7.8:5555 
>   as the destination address of the datagram packet
> SOLUTION II allows us to reuse the existing code, but provides for changing underlying IP addresses.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:12:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 13 Aug 2007 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-4603) How to Find out
 client login time,logout time and what he did in JBoss log
Message-ID: <12408349.1187003521102.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis deleted JBAS-4603:
-------------------------------------


> How to Find out client login time,logout time and what he did in JBoss log
> --------------------------------------------------------------------------
>
>                 Key: JBAS-4603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4603
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>            Reporter: Jaya prakash
>            Priority: Blocker
>
> Here i am facing the issue to find out the user(client) log-in time and log-out time, If he done any thing what he done. I searched in log file but i didn't find out that clearly .
> Please advise me.
> Regards,
> Red 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:35:01 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Mon, 13 Aug 2007 07:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27641857.1187004901200.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371844 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Hi Koen,
by accident I stumbled over the same problem today.
Your patch does not work completey in my case because you do not set the factory before you call adapt().
As a consequence XMLAdapter.isAdapterFor(type) fails, because the factory is null.
So probably you have to call setFactory() twice - once before and once after calling adapt().


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:47:01 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Mon, 13 Aug 2007 07:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9560310.1187005621247.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371846 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Ok, putting another setFactory() before adapt() call in XMLAdapterFactory.createAdapter() makes my use case work.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:49:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7103361.1187005741468.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12371847 ] 
            
Koen Aers commented on GPD-78:
------------------------------

John & Imran,

I have just committed some changes that are supposed to fix this. Can you check if it works and report back?

Regards,
Koen

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Mon Aug 13 08:13:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 08:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28997687.1187007181059.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371851 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Matthias, I have simply *moved* the setFactory() before adapt(). Does that work as well?


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 08:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12332686.1187007781072.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371852 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

Hi Ross,

I can't reproduce this bug. Probably I am not exactly doing the same thing as you do, so could you please describe step by step the manipulations you do. What mouseclicks on what panels, etc.
It doesn't look like an OSX problem, though it could be one. So if anyone has the same problem on a Windows or Linux machine, please join in.
Ross, I believe there was a forum post about this as well. Can you do an update of this post to ask anyone else to report?

Regards,
Koen

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Mon Aug 13 08:33:01 2007
From: jira-events at lists.jboss.org (Przemyslaw Dej (JIRA))
Date: Mon, 13 Aug 2007 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-2) Search Engine
Message-ID: <5001745.1187008381789.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Przemyslaw Dej reassigned JBFORUMS-2:
-------------------------------------

    Assignee: Przemyslaw Dej  (was: Ryszard Kozmik)

> Search Engine
> -------------
>
>                 Key: JBFORUMS-2
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-2
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum View Layer, Forum Enhancements, Forum Model Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Przemyslaw Dej
>            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 lists.jboss.org  Mon Aug 13 08:35:00 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 08:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-137) problem configuriing
	exception class
In-Reply-To: <7080582.1186577089238.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10909987.1187008500998.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-137?page=all ]

Koen Aers closed GPD-137.
-------------------------

    Resolution: Done

> problem configuriing exception class
> ------------------------------------
>
>                 Key: GPD-137
>                 URL: http://jira.jboss.com/jira/browse/GPD-137
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:37:01 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Mon, 13 Aug 2007 08:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1078) Allow static
 expressions in value restrictions
Message-ID: <2496000.1187008621204.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow static expressions in value restrictions
----------------------------------------------

                 Key: JBRULES-1078
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1078
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Alexandre Gattiker
         Assigned To: Mark Proctor


Would it be possible to allow the following two rules to work? In 4.0.0.GA, I get parsing errors for both.

rule "sample rule 1"
	when
		Object(toString == String.valueOf("196071"))
	then
		System.out.println("ok");
end

rule "sample rule 2"
	when
		Object(toString == new String("196071"))
	then
		System.out.println("ok");
end		

(In my particular case, I need to compare BigDecimal values).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:41:02 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Mon, 13 Aug 2007 08:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33461354.1187008862691.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371854 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

Koen, sorry I just couldnt find any other way to make it work. Your update works just fine for me now though. I am creating nodes as well as saving and loading them all correctly. This supports the use cases I have so far and I am closing the issue. Thanks!


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:41:03 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Mon, 13 Aug 2007 08:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-111) Add ability to forward
 and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26447600.1187008863126.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Matthew Sandoz closed GPD-111.
------------------------------

    Resolution: Done

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:41:03 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Mon, 13 Aug 2007 08:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1313091.1187008863400.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371855 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Yes it works, because in my case the "result" object returned by adapt() is identical to the one created before.

I just want to note, that - with this change - you expect that adapt() returns a well configured adapter, which is probably correct.

To make it short, I am happy with this change :).

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:48:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Aug 2007 08:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-200) Make sure the
 batch and sh files work
Message-ID: <27829646.1187009281275.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

So fix the encoding :-)

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:52:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Aug 2007 08:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-382) Remove Complex
 Advice Signatures from Classic Mode
In-Reply-To: <23885199.1176740459311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25305106.1187009521430.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Just move args to only run with generatedadvisors, i.e move it from base-tests.xml to the loadtime and compile-time generated adviosr test targets in build-tests-jdk14.xml and build-tests-jdk50.xml

> Remove Complex Advice Signatures from Classic Mode
> --------------------------------------------------
>
>                 Key: JBAOP-382
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-382
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We need to update PerVMAdvice class, to remove the possibility of advices that receive joinpoint arguments (currently, the matching of parameters is not completely functional).
> We will leave the possibility of receiving joinpoint arguments as parameters to the annotated-parameters signature.
> This task also includes moving arg tests to beforeafterArgs package.
> PS: documentation is already stating that only annotated-parameters advice signatures can feature joinpoint arguments as parameters. No need to update documentation here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:57:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 13 Aug 2007 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1078) Allow static
 expressions in value restrictions
In-Reply-To: <2496000.1187008621204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4597997.1187009821161.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

4.0 will already compare BigDecimals for you, it will always attempt to coerce the values into appropriate formats. The comparison you are trying to do will need to use a return value field constraint, just wrpa it in paranthesis pair of brackets.
Object(toString == ( String.valueOf("196071") ) ) 

> Allow static expressions in value restrictions
> ----------------------------------------------
>
>                 Key: JBRULES-1078
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1078
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexandre Gattiker
>         Assigned To: Mark Proctor
>
> Would it be possible to allow the following two rules to work? In 4.0.0.GA, I get parsing errors for both.
> rule "sample rule 1"
> 	when
> 		Object(toString == String.valueOf("196071"))
> 	then
> 		System.out.println("ok");
> end
> rule "sample rule 2"
> 	when
> 		Object(toString == new String("196071"))
> 	then
> 		System.out.println("ok");
> end		
> (In my particular case, I need to compare BigDecimal values).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:57:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 13 Aug 2007 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1078) Allow static
 expressions in value restrictions
In-Reply-To: <2496000.1187008621204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4898260.1187009821322.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1078.
---------------------------------

    Resolution: Rejected

no bug is given here, this was really a user mailing list Q.

> Allow static expressions in value restrictions
> ----------------------------------------------
>
>                 Key: JBRULES-1078
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1078
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexandre Gattiker
>         Assigned To: Mark Proctor
>
> Would it be possible to allow the following two rules to work? In 4.0.0.GA, I get parsing errors for both.
> rule "sample rule 1"
> 	when
> 		Object(toString == String.valueOf("196071"))
> 	then
> 		System.out.println("ok");
> end
> rule "sample rule 2"
> 	when
> 		Object(toString == new String("196071"))
> 	then
> 		System.out.println("ok");
> end		
> (In my particular case, I need to compare BigDecimal values).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:06:03 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 13 Aug 2007 10:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-4600) Rename JBossMQ
 variables from
 jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into
 build-thirdparty
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1425653.1187013963347.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis reopened JBAS-4600:
--------------------------------------

             
I'm ok with the messaging-mq property rename:

-         <path refid="jboss.messaging.classpath"/>
+         <path refid="jboss.messaging-mq.classpath"/> 

But I don't think we need JBM in Branch_4_2, if it's not used there. I'm thinking of possibly reverting those two:

- the inclusion of JBM in build-thirdparty.xml, and the new target in build-distr.xml
- altering conf/login-config.xml and installing messaging users/roles by default, even if it is not used.

We'll discuss this in an email thread.


> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:49:01 2007
From: jira-events at lists.jboss.org (Rakesh Ajmera (JIRA))
Date: Mon, 13 Aug 2007 10:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1628) Portal bridge
	upgrade
Message-ID: <17053523.1187016541409.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portal bridge upgrade
---------------------

                 Key: JBPORTAL-1628
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1628
             Project: JBoss Portal
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.1 SP1
            Reporter: Rakesh Ajmera


There is a new version of portal-bridge available 1.0.3(http://portals.apache.org/bridges/download.html). What's the plan of upgrading jboss portal to the latest version of portal bridge?

We need the bug fixes available in this 1.0.3 release, but it doesn't work with the jboss's portal-bridge-lib.jar that is packaged with jboss portal.   We are using Struts bridge, that is dependent on the portals-bridges-common.jar, which in turn works with JBoss's potal-bridge-lib.jar. I upgraded the portal-bridges-common.jar with the latest version, but it didn't work with portal-bridge-lib.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 lists.jboss.org  Mon Aug 13 10:54:01 2007
From: jira-events at lists.jboss.org (Marcel Lanz (JIRA))
Date: Mon, 13 Aug 2007 10:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1038) getNodeTypes() and
 getNodeNames() are switched in org.jbpm.graph.node.NodeTypes
Message-ID: <6208587.1187016841947.JavaMail.jira@cloud.prod.atl2.jboss.com>

getNodeTypes() and getNodeNames() are switched in org.jbpm.graph.node.NodeTypes
-------------------------------------------------------------------------------

                 Key: JBPM-1038
                 URL: http://jira.jboss.com/jira/browse/JBPM-1038
             Project: JBoss jBPM
          Issue Type: Bug
    Affects Versions: jBPM jPDL 3.2
            Reporter: Marcel Lanz
         Assigned To: Tom Baeyens
            Priority: Minor


getNodeTypes() is returning nodeNames and getNodeNames() returns the nodeTypes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:54:03 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 10:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1616) Portal link
 should redirect to the default page of the default portal
In-Reply-To: <29869829.1185805429311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32195823.1187016843677.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1616.
------------------------------------

    Resolution: Done

> Portal link should redirect to the default page of the default portal
> ---------------------------------------------------------------------
>
>                 Key: JBPORTAL-1616
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1616
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:54:04 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 10:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1324) Multiple
 portals / custom url : set the default portal name
In-Reply-To: <14061068.1174504436638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21215025.1187016844081.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1324.
------------------------------------

    Resolution: Done

> Multiple portals / custom url : set the default portal name
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1324
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1324
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: JBoss Portal 2.4.0 final
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Here the code of the jmx service class
> public class ConfigurableDefaultPortalCommandFactory extends
> 		DefaultPortalCommandFactory {
> 	private static final Log logger = LogFactory
> 			.getLog(ConfigurableDefaultPortalCommandFactory.class);
> 	/**
> 	 * The JMX attribute for default portal name.
> 	 */
> 	private String defaultPortalName;
> 	/**
> 	 * 
> 	 */
> 	public ConfigurableDefaultPortalCommandFactory() {
> 		super();
> 	}
> 	/*
> 	 * (non-Javadoc)
> 	 * 
> 	 * @see org.jboss.portal.core.model.portal.DefaultPortalCommandFactory#doMapping(org.jboss.portal.server.ServerInvocation,
> 	 *      java.lang.String, java.lang.String)
> 	 */
> 	public ControllerCommand doMapping(ServerInvocation invocation,
> 			String portalContextPath, String portalRequestPath) {
> 		// orginal code : ControllerCommand cmd =
> 		// nextFactory.doMapping(invocation,
> 		ControllerCommand cmd = getNextFactory().doMapping(invocation,
> 				portalContextPath, portalRequestPath);
> 		if (cmd == null) {
> 			// orginal code : Context ctx = container.getContext();
> 			Context ctx = getContainer().getContext();
> 			if (ctx == null) {
> 				throw new IllegalStateException(
> 						"Default context does not exist");
> 			}
> 			// orginal code : Portal portal = ctx.getDefaultPortal();
> 			PortalObject portalObject = ctx.getChild(getDefaultPortalName());
> 			if (portalObject == null) {
> 				throw new IllegalStateException(
> 						"PortalObject as Default Portal is not found. Default Portal name is defined to : "
> 								+ getDefaultPortalName());
> 			}
> 			Portal portal = null;
> 			if (portalObject instanceof Portal) {
> 				portal = (Portal) portalObject;
> 			} else {
> 				throw new IllegalStateException(
> 						"Can't find PortalObject with default portal name : "
> 								+ getDefaultPortalName());
> 			}
> 			// if (portal == null) {
> 			// throw new IllegalStateException("Default portal does not exist");
> 			// }
> 			Page page = portal.getDefaultPage();
> 			if (page == null) {
> 				throw new IllegalStateException("Default page does not exist");
> 			}
> 			String handle = page.getId();
> 			cmd = new RenderPageCommand(handle);
> 		}
> 		return cmd;
> 	}
> 	/**
> 	 * The JMX attribute for default portal name.
> 	 * 
> 	 * @return the defaultPortalName
> 	 */
> 	public String getDefaultPortalName() {
> 		return this.defaultPortalName;
> 	}
> 	/**
> 	 * The JMX attribute for default portal name.
> 	 * 
> 	 * @param defaultPortalName
> 	 *            the defaultPortalName to set
> 	 */
> 	public void setDefaultPortalName(String defaultPortalName) {
> 		this.defaultPortalName = defaultPortalName;
> 	}
> 	/**
> 	 * Call the super method first, then check the {@link #defaultPortalName} is
> 	 * not null and not "". Throw an exception if so.
> 	 */
> 	protected void createService() throws Exception {
> 		super.createService();
> 		if (getDefaultPortalName() == null
> 				|| getDefaultPortalName().compareTo("") == 0) {
> 			throw new Exception(
> 					"The attribute DefaultPortalName can't be null or empty string. Set it in the JMX service descriptor.");
> 		}
> 	}
> 	/*
> 	 * (non-Javadoc)
> 	 * 
> 	 * @see org.jboss.system.ServiceMBeanSupport#startService()
> 	 */
> 	@Override
> 	protected void startService() throws Exception {
> 		logger.info(this.getName() + " service starting. Default portal name : getDefaultPortalName() = "+getDefaultPortalName());
> 		super.startService();
> 	}
> 	/*
> 	 * (non-Javadoc)
> 	 * 
> 	 * @see org.jboss.system.ServiceMBeanSupport#stopService()
> 	 */
> 	@Override
> 	protected void stopService() throws Exception {
> 		super.stopService();
> 		logger.info(this.getName() + " service stoping.");
> 	}
> }
> And add the attribute in the jmx service descriptor :
> <!-- Default portal name : "default" is the default for native jboss portal (downloaded version). -->
> <attribute name="DefaultPortalName">MyDefaultPortalNameHere</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 lists.jboss.org  Mon Aug 13 10:58:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 10:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1628) Portal bridge
	upgrade
In-Reply-To: <17053523.1187016541409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26583356.1187017081051.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1628:
-----------------------------------

      Component/s: Portal Core
    Fix Version/s: 2.4.2 Final
                   2.6.2 Final
                   2.8 Final

> Portal bridge upgrade
> ---------------------
>
>                 Key: JBPORTAL-1628
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1628
>             Project: JBoss Portal
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 SP1
>            Reporter: Rakesh Ajmera
>             Fix For: 2.4.2 Final, 2.8 Final, 2.6.2 Final
>
>
> There is a new version of portal-bridge available 1.0.3(http://portals.apache.org/bridges/download.html). What's the plan of upgrading jboss portal to the latest version of portal bridge?
> We need the bug fixes available in this 1.0.3 release, but it doesn't work with the jboss's portal-bridge-lib.jar that is packaged with jboss portal.   We are using Struts bridge, that is dependent on the portals-bridges-common.jar, which in turn works with JBoss's potal-bridge-lib.jar. I upgraded the portal-bridges-common.jar with the latest version, but it didn't work with portal-bridge-lib.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 lists.jboss.org  Mon Aug 13 11:55:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 11:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1325)
 ConsumerCacheInterceptor : should not use the cache just after login
In-Reply-To: <23196461.1174510488890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13238247.1187020501563.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1325?page=comments#action_12371887 ] 
            
Thomas Heute commented on JBPORTAL-1325:
----------------------------------------

Antoine, did you check on 2.6 ?
I'm not sure i understood your issue, so i cannot try it myself.

> ConsumerCacheInterceptor : should not use the cache just after login
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1325
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1325
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: jbp 2.4.0
>            Reporter: Antoine Herzog
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Use case : 
>  - user come to the site. 
>  - Portlet show views for unchecked user. These views are put in the cache.
>  - user log in, let's say as admin
>  - the cached views still show the previous things, not taking into account the change of authorizations
>  - the user can't see the proper things
> usual needs :
>  - for I18n portals : change of locale when user log in. all the portlets must do the change, not depending on cache
>  - for admin or special roles features in the  portlet views
>  - for modes depending on roles (see forum post)
> In the default portal, there are no use of cache. so all these use cases are fullfiled.
> to reproduce the problem : 
>  - put some cache on the user portlet (great feature for prod), the user portlet window may not update after logging.
> resolution :
> in the ConsumerCacheInterceptor
> the CacheKey do not take into account the login state.
> see : public CacheKey(StateString navigationalState, WindowState windowState, Mode mode)
> so store the user name (or "unchecked") in the CacheEntry.
> put the parameter "userOfFragment" in the CacheKey.
> when retrieving the CacheEntry, compare the currentUser and the userOfFragment, and don't use the cache if different.
> just to see : can we have access to the logued user in this interceptor ? (that, i don't know)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 11:57:43 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 11:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28920754.1187020663917.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12371888 ] 
            
Thomas Heute commented on JBPORTAL-1499:
----------------------------------------

Sohil, Antoine,

What's the conclusion of this ?

> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:16:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1029) Deadlock in
 messaging postoffice
In-Reply-To: <28783104.1186597549324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12745859.1187021761298.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1029.
--------------------------------

    Resolution: Done

> Deadlock in messaging postoffice
> --------------------------------
>
>                 Key: JBMESSAGING-1029
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1029
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-603) Performance
	graphs
In-Reply-To: <23921338.1160165441490.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4319572.1187021881257.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-603:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Performance graphs
> ------------------
>
>                 Key: JBMESSAGING-603
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-603
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>             Fix For: Unscheduled
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-718) Define
 performance criteria for Remoting
In-Reply-To: <22264608.1167850659041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4033902.1187021881457.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-718:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Define performance criteria for Remoting
> ----------------------------------------
>
>                 Key: JBMESSAGING-718
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-718
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>             Fix For: Unscheduled
>
>
> Tom Elrod: Another thing I think we need to work out is some kind of criteria for knowing when remoting has reached the performance level required for messaging.  Currently I have no way of knowing at what point remoting would be sufficiently 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 lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-942) Performance
	comparisons
In-Reply-To: <2148587.1176983619628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27388237.1187021881651.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-942:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Performance comparisons
> -----------------------
>
>                 Key: JBMESSAGING-942
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-942
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>             Fix For: Unscheduled
>
>
> We need to make perfomance comparisons between JBR and MINA.
> Also between JBM and ActiveMQ and QPid

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-412) Please use
 build.properties
 for jboss.home in examples and the auto-install script
Message-ID: <11332775.1187021881821.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-412:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Please use build.properties for jboss.home in examples and the auto-install script
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-412
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-412
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Build System
>            Reporter: Michael Yuan
>            Priority: Minor
>             Fix For: 2.0.0 Beta 1
>
>
> Right now, the build relies on JBOSS_HOME system variable. It is not the way most other projects do and it is broken on Mac. I would suggest to use a build.properties file in the root of the distribution. It has a jboss.home property that the user can edit. The user edits it once and can then use all ant tasks (auto install, examples etc.) in 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 lists.jboss.org  Mon Aug 13 13:02:01 2007
From: jira-events at lists.jboss.org (zhou guangzhao (JIRA))
Date: Mon, 13 Aug 2007 13:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1039) OutOfMemoryError
 While using multi h:selectOneRaido in dataform with multy columns
Message-ID: <21038826.1187024521208.JavaMail.jira@cloud.prod.atl2.jboss.com>

OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns
----------------------------------------------------------------------------------

                 Key: JBPM-1039
                 URL: http://jira.jboss.com/jira/browse/JBPM-1039
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Web Interface
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: jBPM 3.2.1     Tomcat 6.0.14
            Reporter: zhou guangzhao
         Assigned To: Tom Baeyens


The following taskform code works in JBPM3.2.GA. 
But when running in JBPM 3.2.1, it causes OutOfMemoryError. By testing, I found that if I change <jbpm:dataform columns="2"> to <jbpm:dataform>, it will work well in both JBPM3.2.GA and JBPM3.2.1. 
Sometimes it maybe works in JBPM3.2.1. But while adding more h:selectOneRadio,  I get the error.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >

<!-- the DOCTYPE means we are required to use html for a root element -->
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:c="http://java.sun.com/jstl/core"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:tf="http://jbpm.org/jsf/tf"
      xmlns:jbpm="http://jbpm.org/jsf">

  <ui:component>

    <jbpm:dataform columns="2">
  	
      <f:facet name="header">
        <h:outputText value="#{taskName}"/>
      </f:facet>
        
      <!-- TASKFORM ROWS -->
      <jbpm:datacell>
        <f:facet name="header">
            <h:outputText value="Sex"/>
        </f:facet>
        <h:selectOneRadio id="StudentSex" value="#{var['StudentSex']}"> 
			<f:selectItem itemLabel="Male" itemValue="Male"/>
	        <f:selectItem itemLabel="Female" itemValue="Female"/> 
	    </h:selectOneRadio>  
      </jbpm:datacell>

     <jbpm:datacell>
        <f:facet name="header">
            <h:outputText value="HasAS"/>
        </f:facet>
        <h:selectOneRadio id="HasAS" value="#{var['HasAS']}" >
      	    <f:selectItem itemLabel="Yes" itemValue="Yes"/>
	        <f:selectItem itemLabel="No" itemValue="No"/> 
	    </h:selectOneRadio>
      </jbpm:datacell>
    	    	    
      <jbpm:datacell>
        <f:facet name="header">
          <h:outputText value="Actions"/>
        </f:facet>
        <!-- TASKFORM BUTTONS -->
        <tf:saveButton value="Save"/>
        <tf:cancelButton value="Cancel"/>
        <tf:transitionButton value="Save and Close"/>
      </jbpm:datacell>
	    
    </jbpm:dataform>	
    
  </ui:component>

</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 lists.jboss.org  Mon Aug 13 13:18:01 2007
From: jira-events at lists.jboss.org (zhou guangzhao (JIRA))
Date: Mon, 13 Aug 2007 13:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1040) Improve
 jbpm:datacell with cross columns and rows feature
Message-ID: <16854121.1187025481280.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve jbpm:datacell with cross columns and rows feature
---------------------------------------------------------

                 Key: JBPM-1040
                 URL: http://jira.jboss.com/jira/browse/JBPM-1040
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Web Interface
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: zhou guangzhao
         Assigned To: Tom Baeyens


The tag <jbpm:dataform> now has attribute "columns" that makes the table has multi columns.
But each <jpbm:datacell> can only occupy one cell in the table generated automatically by dataform.
In some cases, user need a datacell to cross more columns or rows. 
So it is necessary to add the feature as title.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 14:13:13 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 13 Aug 2007 14:13:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4604) NamingContext does
 not take
 potential AutoDiscoveryAddress XML property overrides when sending
 discovery requests
Message-ID: <26585393.1187028793738.JavaMail.jira@cloud.prod.atl2.jboss.com>

NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests
-----------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4604
                 URL: http://jira.jboss.com/jira/browse/JBAS-4604
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Galder Zamarreno
         Assigned To: Brian Stansberry
            Priority: Minor


Bug in org.jnp.interfaces.NamingContext:

discoverServer(Hashtable) method

String group = DEFAULT_DISCOVERY_GROUP_ADDRESS;
...
String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP);
if (discoveryGroup != null)
group = discoveryGroup;
...
iaGroup = InetAddress.getByName(group);
....
if (trace)
log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port);

NamingContext code does not take in account possible system property overrides
coming from:

<attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>

AutoDiscoveryAddress used to send discovery messages is controlled via the the
default value, 230.0.0.4 or jnp.discoveryGroup property. 

So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, 
DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while 
NamingContext sends discovery requests to 230.0.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 lists.jboss.org  Mon Aug 13 14:20:19 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 13 Aug 2007 14:20:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4604) NamingContext does
 not take
 potential AutoDiscoveryAddress XML property overrides when sending
 discovery requests
In-Reply-To: <26585393.1187028793738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13773402.1187029219064.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Galder Zamarreno updated JBAS-4604:
-----------------------------------

    Workaround Description: 
There's 3 possible workarounds:

- remove XML override from AutoDiscoveryAddress, i.e:

<attribute name="AutoDiscoveryAddress">230.0.0.4</attribute>

- use a different XML override name so that jboss.partition.udpGroup use is liberated:

<attribute name="AutoDiscoveryAddress">${jboss.partition.autoDiscoveryGroup:230.0.0.4}</attribute>

- set AutoDiscoveryGroup via jnp.discoveryGroup system property, see:

http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingContextFactory

> NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4604
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4604
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Naming
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> Bug in org.jnp.interfaces.NamingContext:
> discoverServer(Hashtable) method
> String group = DEFAULT_DISCOVERY_GROUP_ADDRESS;
> ...
> String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP);
> if (discoveryGroup != null)
> group = discoveryGroup;
> ...
> iaGroup = InetAddress.getByName(group);
> ....
> if (trace)
> log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port);
> NamingContext code does not take in account possible system property overrides
> coming from:
> <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>
> AutoDiscoveryAddress used to send discovery messages is controlled via the the
> default value, 230.0.0.4 or jnp.discoveryGroup property. 
> So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, 
> DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while 
> NamingContext sends discovery requests to 230.0.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 lists.jboss.org  Mon Aug 13 14:22:01 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 13 Aug 2007 14:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4604) NamingContext does
 not take
 potential AutoDiscoveryAddress XML property overrides when sending
 discovery requests
In-Reply-To: <26585393.1187028793738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14761814.1187029321185.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Galder Zamarreno updated JBAS-4604:
-----------------------------------

    Workaround Description: 
There're 3 possible workarounds:

1.- remove XML override from AutoDiscoveryAddress, i.e:
<attribute name="AutoDiscoveryAddress">230.0.0.4</attribute>

2.- use a different XML override name so that jboss.partition.udpGroup confusion is avoided, but 
without setting this property on startup! :
<attribute name="AutoDiscoveryAddress">${jboss.partition.autoDiscoveryGroup:230.0.0.4}</attribute>

3.- set AutoDiscoveryGroup via jnp.discoveryGroup system property, see:
http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingContextFactory

  was:
There's 3 possible workarounds:

- remove XML override from AutoDiscoveryAddress, i.e:

<attribute name="AutoDiscoveryAddress">230.0.0.4</attribute>

- use a different XML override name so that jboss.partition.udpGroup use is liberated:

<attribute name="AutoDiscoveryAddress">${jboss.partition.autoDiscoveryGroup:230.0.0.4}</attribute>

- set AutoDiscoveryGroup via jnp.discoveryGroup system property, see:

http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingContextFactory


> NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4604
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4604
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Naming
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> Bug in org.jnp.interfaces.NamingContext:
> discoverServer(Hashtable) method
> String group = DEFAULT_DISCOVERY_GROUP_ADDRESS;
> ...
> String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP);
> if (discoveryGroup != null)
> group = discoveryGroup;
> ...
> iaGroup = InetAddress.getByName(group);
> ....
> if (trace)
> log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port);
> NamingContext code does not take in account possible system property overrides
> coming from:
> <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>
> AutoDiscoveryAddress used to send discovery messages is controlled via the the
> default value, 230.0.0.4 or jnp.discoveryGroup property. 
> So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, 
> DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while 
> NamingContext sends discovery requests to 230.0.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 lists.jboss.org  Mon Aug 13 14:33:01 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Mon, 13 Aug 2007 14:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1079) Problem with "!="
 field constraint
Message-ID: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem with "!=" field constraint
----------------------------------

                 Key: JBRULES-1079
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Markus Reitz
         Assigned To: Mark Proctor


The following code illustrates the problem.

import org.drools.*;
import org.drools.compiler.*;
import org.drools.rule.Package;

import java.io.*;

public class DroolsTest {
  private RuleBase        rules;
  private StatefulSession memory;

  public DroolsTest(File file) throws Exception {
    rules =RuleBaseFactory.newRuleBase();
    memory=rules.newStatefulSession();
    
    rules.addPackage(loadPackage(file));
  }

  protected Package loadPackage(File file) throws IOException {
    FileInputStream stream=null;
    
    try {
      stream=new FileInputStream(file);
    
      return(loadPackage(stream));
    }
    finally {
      if (stream!=null)
        stream.close();
    }
  }

  protected Package loadPackage(InputStream stream) throws IOException {
    try {
      PackageBuilder builder=new PackageBuilder();

      builder.addPackageFromDrl(new InputStreamReader(stream));

      return(builder.getPackage());
    }
    catch(Exception ex) {
      throw new IOException();
    }
  }
  
  public StatefulSession getSession() {
    return(memory);
  }
  
  public static void main(String ... args) {
    try {
      DroolsTest test=new DroolsTest(new File(args[0]));
      
      SpecialString first42 =new SpecialString("42");
      SpecialString second42=new SpecialString("42");
      
      test.getSession().insert(new SpecialString("World"));
      test.getSession().insert(first42);
      test.getSession().insert(second42);
      
      System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
      System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
      
      System.out.println("Firing rules ...");
      
      test.getSession().fireAllRules();
    }
    catch (Exception ex) {
      ex.printStackTrace();
    }
  }
}

In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".

The class SpecialString uses the standard equals(...) and hashCode(...) implementation:

public class SpecialString {
  private String text;
  
  public SpecialString(String text) {
    this.text=text;
  }
  
  public String getText() {
    return(text);
  }
  
  @Override public String toString() {
    return(getText()+"["+super.toString()+"]");
  }
}

For the rule

  package test

  rule "A test"

    when
      x : SpecialString()
      y : SpecialString(this!=x)

    then
      System.out.println(x+"/"+y);
  end

The output is 

  Fact handle: [fid:2:2:42[SpecialString at fde8da]]
  Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
  Firing rules ...
  42[SpecialString at e4d6ef]/World[SpecialString at faa824]
  World[SpecialString at faa824]/42[SpecialString at e4d6ef]
  42[SpecialString at fde8da]/World[SpecialString at faa824]
  World[SpecialString at faa824]/42[SpecialString at fde8da]

I would expect that

  42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
  42[SpecialString at fde8da]/42[SpecialString at e4d6ef]

is also contained in the output, but this is not the 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 lists.jboss.org  Mon Aug 13 14:43:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Mon, 13 Aug 2007 14:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1325)
 ConsumerCacheInterceptor : should not use the cache just after login
In-Reply-To: <23196461.1174510488890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7457646.1187030581531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1325?page=comments#action_12371905 ] 
            
Antoine Herzog commented on JBPORTAL-1325:
------------------------------------------


This is not an issue..... (I did this jira in march when exploring things about cache... did not see the thing explained since by Julien).

Should be closed. 
(see comments yet above).

about checking : this was asked by Julien, but I think it was "just in case..."
I don't think it is usefull.

not yet using the cache with 2.6 (don't want to add this while starting some ajax stuff).... 

if I see something, I'll reopen this... but sure it won't be necessary.




> ConsumerCacheInterceptor : should not use the cache just after login
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1325
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1325
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: jbp 2.4.0
>            Reporter: Antoine Herzog
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Use case : 
>  - user come to the site. 
>  - Portlet show views for unchecked user. These views are put in the cache.
>  - user log in, let's say as admin
>  - the cached views still show the previous things, not taking into account the change of authorizations
>  - the user can't see the proper things
> usual needs :
>  - for I18n portals : change of locale when user log in. all the portlets must do the change, not depending on cache
>  - for admin or special roles features in the  portlet views
>  - for modes depending on roles (see forum post)
> In the default portal, there are no use of cache. so all these use cases are fullfiled.
> to reproduce the problem : 
>  - put some cache on the user portlet (great feature for prod), the user portlet window may not update after logging.
> resolution :
> in the ConsumerCacheInterceptor
> the CacheKey do not take into account the login state.
> see : public CacheKey(StateString navigationalState, WindowState windowState, Mode mode)
> so store the user name (or "unchecked") in the CacheEntry.
> put the parameter "userOfFragment" in the CacheKey.
> when retrieving the CacheEntry, compare the currentUser and the userOfFragment, and don't use the cache if different.
> just to see : can we have access to the logued user in this interceptor ? (that, i don't know)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:01:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Aug 2007 15:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24023551.1187031661423.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1079:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Mon Aug 13 15:14:05 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 15:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1163) Add FQN versions
 of POJO Cache methods
Message-ID: <9866311.1187032445517.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add FQN versions of POJO Cache methods
--------------------------------------

                 Key: JBCACHE-1163
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1163
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Jason T. Greene
         Assigned To: Jason T. Greene
             Fix For: 2.1.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:46:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Mon, 13 Aug 2007 15:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14721459.1187034361544.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12371910 ] 
            
Antoine Herzog commented on JBPORTAL-1499:
------------------------------------------

I opened a design forum post :
http://jboss.org/index.html?module=bb&op=viewtopic&t=115999

and put a post on this one :
http://jboss.org/index.html?module=bb&op=viewtopic&t=112843

hope that something will get out.

For the time being : can't use the CMS full feature with security constraint on each docs, if you want a CMS repo datasource different from the Identity Hibernate datasource.

And can't say for a prod environnement : let's mix the tables of CMS and Identity in the same database...
The prod admin will manage to backup, move from dev to prod... checking each time what table to take, what not to touch etc...





> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:55:01 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 13 Aug 2007 15:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
Message-ID: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>

JSP compiler won't compile JDK 1.5 source
-----------------------------------------

                 Key: JBAS-4605
                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Stan Silvert
         Assigned To: Stan Silvert


>From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:59:11 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Mon, 13 Aug 2007 15:59:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1499) CMSAdminPortlet
 should use Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12683346.1187035151558.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sohil Shah updated JBPORTAL-1499:
---------------------------------

    JBoss Forum Reference: http://jboss.org/index.html?module=bb&op=viewtopic&t=115999

> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 16:18:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Mon, 13 Aug 2007 16:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32216310.1187036281931.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12371916 ] 
            
Sohil Shah commented on JBPORTAL-1499:
--------------------------------------

Based on the discussion,

looks like what we need to do is fix the small bug I mentioned in my earlier comments. With this the HSQL based queries will be used by the Security Engine as a performance optimization, only for the DB based Identity Module that ships with the
Portal out-of-the-box. This module stores data inside the Portal database.

For other implementations of the Identity API which stores data in different stores like LDAP, another database etc, the CMS Security Engine will fall back to use the generic Identity API to gets its information.

In this case however. all performance optimizations will be resposibility of the Identity Module Implementation itself.

> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 17:18:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Aug 2007 17:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
In-Reply-To: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7375317.1187039881398.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry reopened JBAS-3720:
------------------------------------

             
Thanks, Hany. :)  I'm reopening pending getting the test to work; will close once it passes.

> 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: Web (Tomcat) service, Clustering
>            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 lists.jboss.org  Mon Aug 13 17:20:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Aug 2007 17:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
In-Reply-To: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10489867.1187040001072.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry updated JBAS-3720:
-----------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                       (was: JBossAS-5.0.0.CR1)

> 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: Web (Tomcat) service, Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> 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 lists.jboss.org  Mon Aug 13 17:22:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 17:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1325)
 ConsumerCacheInterceptor : should not use the cache just after login
In-Reply-To: <23196461.1174510488890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6688364.1187040121808.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1325.
------------------------------------

    Resolution: Won't Fix
      Assignee: Thomas Heute  (was: Julien Viet)

I mark it resolved as "won't fix" then, thanks.

> ConsumerCacheInterceptor : should not use the cache just after login
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1325
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1325
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: jbp 2.4.0
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Use case : 
>  - user come to the site. 
>  - Portlet show views for unchecked user. These views are put in the cache.
>  - user log in, let's say as admin
>  - the cached views still show the previous things, not taking into account the change of authorizations
>  - the user can't see the proper things
> usual needs :
>  - for I18n portals : change of locale when user log in. all the portlets must do the change, not depending on cache
>  - for admin or special roles features in the  portlet views
>  - for modes depending on roles (see forum post)
> In the default portal, there are no use of cache. so all these use cases are fullfiled.
> to reproduce the problem : 
>  - put some cache on the user portlet (great feature for prod), the user portlet window may not update after logging.
> resolution :
> in the ConsumerCacheInterceptor
> the CacheKey do not take into account the login state.
> see : public CacheKey(StateString navigationalState, WindowState windowState, Mode mode)
> so store the user name (or "unchecked") in the CacheEntry.
> put the parameter "userOfFragment" in the CacheKey.
> when retrieving the CacheEntry, compare the currentUser and the userOfFragment, and don't use the cache if different.
> just to see : can we have access to the logued user in this interceptor ? (that, i don't know)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 17:24:01 2007
From: jira-events at lists.jboss.org (Micah Modell (JIRA))
Date: Mon, 13 Aug 2007 17:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-144) Renaming Task and
 Generating Form yields incorrect forms.xml
Message-ID: <28233236.1187040241261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Renaming Task and Generating Form yields incorrect forms.xml
------------------------------------------------------------

                 Key: GPD-144
                 URL: http://jira.jboss.com/jira/browse/GPD-144
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.0.13
         Environment: RHEL 5
Eclipse 3.3
Sun Java 1.5_12
            Reporter: Micah Modell
         Assigned To: Koen Aers


If you create a new task on a TaskNode, rename it in the "General" tab and then use "Generate Form..." in the "Advanced" tab, the forms.xml entry references the original task name rather than the updated one.  This causes the jBPM admin console to be unable to find the task form.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 17:58:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 13 Aug 2007 17:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-383) Complete Retro
	Mavenization
In-Reply-To: <30433964.1181834471757.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25589315.1187042281312.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-383?page=all ]

Paul Gier reassigned JBBUILD-383:
---------------------------------

    Assignee: Paul Gier

> Complete Retro Mavenization
> ---------------------------
>
>                 Key: JBBUILD-383
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-383
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: JBossRetro-1.1.3.GA
>
>
> The mavenization can be completed when the next surefire plugin is released.
> Also there needs to be a way to configure the manifest file for the runtime jar.
> Look into breaking retro into three modules: weaver, retro-runtime, and maven-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 lists.jboss.org  Mon Aug 13 18:42:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 18:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-518) Investigate use a
 new replication schema for PojoCache
Message-ID: <16695928.1187044921291.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ]

Jason T. Greene resolved JBCACHE-518.
-------------------------------------

    Resolution: Rejected

> Investigate use a new replication schema for PojoCache
> ------------------------------------------------------
>
>                 Key: JBCACHE-518
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-518
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>             Fix For: PojoCache 2.2.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive.
> The other issue is what to do with automicity during putObject and removeObject?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 18:46:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 18:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-518) Investigate use a
 new replication schema for PojoCache
Message-ID: <12821170.1187045161225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ]

Jason T. Greene updated JBCACHE-518:
------------------------------------

    Fix Version/s:     (was: PojoCache 2.2.0)

> Investigate use a new replication schema for PojoCache
> ------------------------------------------------------
>
>                 Key: JBCACHE-518
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-518
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive.
> The other issue is what to do with automicity during putObject and removeObject?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:06:17 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-288) Enable garbage
 collection for Pojo under cache management
Message-ID: <6546855.1187046377269.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-288?page=all ]

Jason T. Greene closed JBCACHE-288.
-----------------------------------

    Fix Version/s:     (was: PojoCache)
       Resolution: Rejected

> Enable garbage collection for Pojo under cache management
> ---------------------------------------------------------
>
>                 Key: JBCACHE-288
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-288
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Currently, once the pojo is put into cache, it won't get gced unless user specifically issues removeObject. There is eviction policy. However, it is coupled with cache loader so the object is still around for a specific time span. We should come up with a way to gc these pojos properly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:06:17 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Mon, 13 Aug 2007 19:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1039) OutOfMemoryError
 While using multi h:selectOneRaido in dataform with multy columns
In-Reply-To: <21038826.1187024521208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21655046.1187046377462.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1039?page=all ]

Ronald van Kuijk updated JBPM-1039:
-----------------------------------

    Priority: Minor  (was: Major)

> OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns
> ----------------------------------------------------------------------------------
>
>                 Key: JBPM-1039
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1039
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1     Tomcat 6.0.14
>            Reporter: zhou guangzhao
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> The following taskform code works in JBPM3.2.GA. 
> But when running in JBPM 3.2.1, it causes OutOfMemoryError. By testing, I found that if I change <jbpm:dataform columns="2"> to <jbpm:dataform>, it will work well in both JBPM3.2.GA and JBPM3.2.1. 
> Sometimes it maybe works in JBPM3.2.1. But while adding more h:selectOneRadio,  I get the error.
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
> <!-- the DOCTYPE means we are required to use html for a root element -->
> <html xmlns="http://www.w3.org/1999/xhtml"
>       xmlns:ui="http://java.sun.com/jsf/facelets"
>       xmlns:c="http://java.sun.com/jstl/core"
>       xmlns:h="http://java.sun.com/jsf/html"
>       xmlns:f="http://java.sun.com/jsf/core"
>       xmlns:tf="http://jbpm.org/jsf/tf"
>       xmlns:jbpm="http://jbpm.org/jsf">
>   <ui:component>
>     <jbpm:dataform columns="2">
>   	
>       <f:facet name="header">
>         <h:outputText value="#{taskName}"/>
>       </f:facet>
>         
>       <!-- TASKFORM ROWS -->
>       <jbpm:datacell>
>         <f:facet name="header">
>             <h:outputText value="Sex"/>
>         </f:facet>
>         <h:selectOneRadio id="StudentSex" value="#{var['StudentSex']}"> 
> 			<f:selectItem itemLabel="Male" itemValue="Male"/>
> 	        <f:selectItem itemLabel="Female" itemValue="Female"/> 
> 	    </h:selectOneRadio>  
>       </jbpm:datacell>
>      <jbpm:datacell>
>         <f:facet name="header">
>             <h:outputText value="HasAS"/>
>         </f:facet>
>         <h:selectOneRadio id="HasAS" value="#{var['HasAS']}" >
>       	    <f:selectItem itemLabel="Yes" itemValue="Yes"/>
> 	        <f:selectItem itemLabel="No" itemValue="No"/> 
> 	    </h:selectOneRadio>
>       </jbpm:datacell>
>     	    	    
>       <jbpm:datacell>
>         <f:facet name="header">
>           <h:outputText value="Actions"/>
>         </f:facet>
>         <!-- TASKFORM BUTTONS -->
>         <tf:saveButton value="Save"/>
>         <tf:cancelButton value="Cancel"/>
>         <tf:transitionButton value="Save and Close"/>
>       </jbpm:datacell>
> 	    
>     </jbpm:dataform>	
>     
>   </ui:component>
> </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 lists.jboss.org  Mon Aug 13 19:10:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-281) PojoCahce
 initialize "aspectized" pojos when first retrieved
Message-ID: <4305884.1187046601243.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-281?page=all ]

Jason T. Greene resolved JBCACHE-281.
-------------------------------------

    Fix Version/s:     (was: PojoCache 2.1.0)
       Resolution: Out of Date

This is already done in detach()

> PojoCahce initialize "aspectized" pojos when first retrieved
> ------------------------------------------------------------
>
>                 Key: JBCACHE-281
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-281
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, when we do getObject for the first time, we don't initialize the "aspectized" pojo after a get/set is requested. As a result, some of the fields will be un-initialized untill after they are accessed.
> We need to provide an option to actively initialize the pojos.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:10:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-71) Resizing cache at
	runtime
Message-ID: <26057530.1187046601471.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-71?page=all ]

Jason T. Greene closed JBCACHE-71.
----------------------------------

    Fix Version/s:     (was: 3.0.0)
       Resolution: Out of Date

There is a new region design.

> Resizing cache at runtime
> -------------------------
>
>                 Key: JBCACHE-71
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-71
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> With the dynamic runtime configuration of eviction policy, we should be able to resize the cache at runtime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:12:02 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-318) CacheLoader
 persistent item should have an age limit
Message-ID: <3208022.1187046722414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-318?page=all ]

Jason T. Greene reassigned JBCACHE-318:
---------------------------------------

    Assignee: Manik Surtani  (was: Jason T. Greene)

> CacheLoader persistent item should have an age limit
> ----------------------------------------------------
>
>                 Key: JBCACHE-318
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-318
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Currently items that are persisted has no notion of age out. So let's say it is fairly common in SFSB to have the state not live more than 2 weeks in the store, for example. The other usage is when the cache crashed and the persistent store won't get cleaned up even when the items are orphaned.
> Bela refused to put this functionality in the cache loader layer. So Manik's idea is to wrap around the object in the CacheStoreInterceptor with an additional timestamp. This way an offline thread can come in and clean them.
> We can also check how does the current SFSB does 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 lists.jboss.org  Mon Aug 13 19:14:16 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Mon, 13 Aug 2007 19:14:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1040) Improve
 jbpm:datacell with cross columns and rows feature
In-Reply-To: <16854121.1187025481280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25681034.1187046856829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1040?page=all ]

Ronald van Kuijk updated JBPM-1040:
-----------------------------------

    Priority: Optional  (was: Major)

like the colspan and rowspan in html tables?

> Improve jbpm:datacell with cross columns and rows feature
> ---------------------------------------------------------
>
>                 Key: JBPM-1040
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1040
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Web Interface
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: zhou guangzhao
>         Assigned To: Tom Baeyens
>            Priority: Optional
>
> The tag <jbpm:dataform> now has attribute "columns" that makes the table has multi columns.
> But each <jpbm:datacell> can only occupy one cell in the table generated automatically by dataform.
> In some cases, user need a datacell to cross more columns or rows. 
> So it is necessary to add the feature as title.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 20:05:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 13 Aug 2007 20:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1080) Modify (var)
 added to Eclipse code completion for mvel
Message-ID: <19252810.1187049901307.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify (var) added to Eclipse code completion for mvel
------------------------------------------------------

                 Key: JBRULES-1080
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1080
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 4.0.1
            Reporter: Philippe Ombredanne
         Assigned To: Philippe Ombredanne
            Priority: Minor
         Attachments: mvel.png

Reported by Mark: 
I've found a weird one with context assist, some how its adding "modify ( var )" to the list of context completions, but it only does that if you've already added the line to the consequence. See modify( game ).



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 20:05:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 13 Aug 2007 20:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1080) Modify (var)
 added to Eclipse code completion for mvel
In-Reply-To: <19252810.1187049901307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18971720.1187049901456.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne updated JBRULES-1080:
-----------------------------------------

    Attachment: mvel.png

> Modify (var) added to Eclipse code completion for mvel
> ------------------------------------------------------
>
>                 Key: JBRULES-1080
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1080
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Philippe Ombredanne
>            Priority: Minor
>         Attachments: mvel.png
>
>
> Reported by Mark: 
> I've found a weird one with context assist, some how its adding "modify ( var )" to the list of context completions, but it only does that if you've already added the line to the consequence. See modify( game ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 20:22:01 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Mon, 13 Aug 2007 20:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
Message-ID: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>

Repository exception occurs duing opening, creation of the rules
----------------------------------------------------------------

                 Key: JBRULES-1081
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
         Environment: Standard version of BRMS
            Reporter: Joe Son
         Assigned To: Mark Proctor


I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:

javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent

It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 

Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 21:11:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Mon, 13 Aug 2007 21:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-382) Remove Complex
 Advice Signatures from Classic Mode
In-Reply-To: <23885199.1176740459311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14482314.1187053861268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-382?page=comments#action_12371942 ] 
            
Stale Pedersen commented on JBAOP-382:
--------------------------------------

args tests are moved and method params are now required to implement org.jboss.aop.joinpoint.Invocation

> Remove Complex Advice Signatures from Classic Mode
> --------------------------------------------------
>
>                 Key: JBAOP-382
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-382
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We need to update PerVMAdvice class, to remove the possibility of advices that receive joinpoint arguments (currently, the matching of parameters is not completely functional).
> We will leave the possibility of receiving joinpoint arguments as parameters to the annotated-parameters signature.
> This task also includes moving arg tests to beforeafterArgs package.
> PS: documentation is already stating that only annotated-parameters advice signatures can feature joinpoint arguments as parameters. No need to update documentation here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 22:43:01 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 13 Aug 2007 22:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
In-Reply-To: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11236972.1187059381078.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Stan Silvert updated JBAS-4605:
-------------------------------

    Component/s: Web (Tomcat) service

> JSP compiler won't compile JDK 1.5 source
> -----------------------------------------
>
>                 Key: JBAS-4605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>
> From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 22:45:25 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 13 Aug 2007 22:45:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
In-Reply-To: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12831253.1187059525861.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4605?page=comments#action_12371946 ] 
            
Stan Silvert commented on JBAS-4605:
------------------------------------

This is already fixed in JBoss 5.  We can just add compilerSourceVM to conf/web.xml in the 4.2 branch.

> JSP compiler won't compile JDK 1.5 source
> -----------------------------------------
>
>                 Key: JBAS-4605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>
> From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:03:11 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:03:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-165) Option to exclude
 fields from "aspectized" in aop
Message-ID: <6852910.1187064191225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-165?page=all ]

Jason T. Greene closed JBCACHE-165.
-----------------------------------

    Fix Version/s:     (was: 2.1.0.GA)
       Resolution: Out of Date

See @Transient

> Option to exclude fields from "aspectized" in aop
> -------------------------------------------------
>
>                 Key: JBCACHE-165
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-165
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> There may a time when a user wants certain fields in the POJO to be excluded from TreeCacheAop management. Currently, if a field is declared "transient", we have that effect. But still we may want to have a flag for this specific purpose.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:05:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-663) Setup system
 property for Id string separator
Message-ID: <30847069.1187064301190.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-663?page=all ]

Jason T. Greene resolved JBCACHE-663.
-------------------------------------

    Fix Version/s:     (was: PojoCache)
       Resolution: Rejected

> Setup system property for Id string separator
> ---------------------------------------------
>
>                 Key: JBCACHE-663
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-663
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> In 2.0 release, we will use id String instead the old fqn. We will also use a system property called jbosscache.separator to allow user to use a different character as the separator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:05:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-663) Setup system
 property for Id string separator
Message-ID: <5810358.1187064301408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-663?page=all ]

Jason T. Greene closed JBCACHE-663.
-----------------------------------


> Setup system property for Id string separator
> ---------------------------------------------
>
>                 Key: JBCACHE-663
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-663
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> In 2.0 release, we will use id String instead the old fqn. We will also use a system property called jbosscache.separator to allow user to use a different character as the separator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:09:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-771) PojoCache to have
 events reacting to transactional context
In-Reply-To: <5459146.1158485139891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28298462.1187064541480.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-771?page=all ]

Jason T. Greene resolved JBCACHE-771.
-------------------------------------

    Fix Version/s: 2.0.0.GA
                       (was: 2.1.0.GA)
       Resolution: Done

This was implemented in the notification API of 2.0.0.GA

> 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: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Tue Aug 14 00:14:10 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-925) PojoCache to
 re-try if UpgradeException occur
In-Reply-To: <18289277.1167962066834.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16968110.1187064850838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-925?page=all ]

Jason T. Greene resolved JBCACHE-925.
-------------------------------------

    Fix Version/s:     (was: 2.1.0.GA)
       Resolution: Out of Date

This will no longer be necessary with MVCC

> PojoCache to re-try if UpgradeException occur
> ---------------------------------------------
>
>                 Key: JBCACHE-925
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-925
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>
> Currently, PojoCache attach & detach is prone to encoutner UpgradeException on __JBossInternal__ node. This is becuase of the flat space approach that we use such that all the POJO are stored there. As a result, UpgradeException can happen and we should catch it and re-try 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 lists.jboss.org  Tue Aug 14 01:58:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 01:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1052) When Inserting
 a fact cannot set a String field
In-Reply-To: <1292464.1185911829398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9013397.1187071081145.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1052?page=comments#action_12371956 ] 
            
Michael Neale commented on JBRULES-1052:
----------------------------------------

there is a test for this in the model stuff (so I presume it is infering the type from the model correctly).
Need to confirm that this is a bug in the eclipse tool not the web as well. 

> When Inserting a fact cannot set a String field
> -----------------------------------------------
>
>                 Key: JBRULES-1052
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1052
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> A String field only let me put in numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 02:00:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 02:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-923) change
 BRDRLPersistence to emit packages that use MVEL
In-Reply-To: <4742060.1181727136865.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12097230.1187071201183.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-923.
---------------------------------

    Resolution: Done
      Assignee: Michael Neale  (was: Edson Tirelli)

> change BRDRLPersistence to emit packages that use MVEL
> ------------------------------------------------------
>
>                 Key: JBRULES-923
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-923
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions: 4.0.0.MR2
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> Mark thinks it may be a good idea to generate to MVEL instead of Java - what say you? 
> I think this simply means adding an attribute of "dialect 'mvel' " to the top of the package, and testing.
> Its possible to generate the RHS using the accessors like:
> foo.bar = "value" 
> for assignment - not sure if that is better or 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 lists.jboss.org  Tue Aug 14 02:00:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 02:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5623813.1187071201574.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1081:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

Fer - any clues on how to reproduce? if you can't repo with the info given, close it off. 

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 02:41:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 02:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5802337.1187073661617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12371960 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

waiting for input form Barry...

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Tue Aug 14 03:28:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
Message-ID: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invoke remote EJB3 from JVM 1.4 client
--------------------------------------

                 Key: EJBTHREE-1029
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
             Project: EJB 3.0
          Issue Type: Patch
         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
Client : JDK 1.4.2
            Reporter: Boris Maras


Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.

So I used jbossretro to convert this jar in jdk 1.4 compatible format.
That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)

In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
- the client jar for your EJBs
- the generated jboss-ejb3-client14.jar
- jbossretro-rt.jar
- jboss-backport-concurrent.jar
- javassist.jar

I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.

I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.

I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
- uncompress the file jboss-ejb3.jar
- delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
- run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
- recompress the jar

This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 03:31:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
In-Reply-To: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28861379.1187076661155.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boris Maras updated EJBTHREE-1029:
----------------------------------

    Attachment: patch build.xml ejb3-client1.4.txt

Path for the current version of file ejb3/build.xml
It generates a new file : jboss-ejb3-client14.jar that can be used to call remote EJB3s from a JVM 1.4 client

> Invoke remote EJB3 from JVM 1.4 client
> --------------------------------------
>
>                 Key: EJBTHREE-1029
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
>             Project: EJB 3.0
>          Issue Type: Patch
>         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
> Client : JDK 1.4.2
>            Reporter: Boris Maras
>         Attachments: patch build.xml ejb3-client1.4.txt
>
>
> Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.
> So I used jbossretro to convert this jar in jdk 1.4 compatible format.
> That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)
> In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
> - the client jar for your EJBs
> - the generated jboss-ejb3-client14.jar
> - jbossretro-rt.jar
> - jboss-backport-concurrent.jar
> - javassist.jar
> I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.
> I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.
> I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
> - uncompress the file jboss-ejb3.jar
> - delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
> - run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
> - recompress the jar
> This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 03:34:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
In-Reply-To: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11171459.1187076841078.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boris Maras updated EJBTHREE-1029:
----------------------------------

    Attachment: build-client1.4convert.xml

This ant script uses an existing jboss-ejb3.jar to generate a jboss-ejb3-client14.jar that can be used to call remote EJB3s from a jvm 1.4 client.
I created this ant script to be able to generate this jar on older versions of JBoss & EJB3.
I tested it on JBoss 4.0.3SP1 and EJB3 RC6

> Invoke remote EJB3 from JVM 1.4 client
> --------------------------------------
>
>                 Key: EJBTHREE-1029
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
>             Project: EJB 3.0
>          Issue Type: Patch
>         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
> Client : JDK 1.4.2
>            Reporter: Boris Maras
>         Attachments: build-client1.4convert.xml, patch build.xml ejb3-client1.4.txt
>
>
> Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.
> So I used jbossretro to convert this jar in jdk 1.4 compatible format.
> That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)
> In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
> - the client jar for your EJBs
> - the generated jboss-ejb3-client14.jar
> - jbossretro-rt.jar
> - jboss-backport-concurrent.jar
> - javassist.jar
> I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.
> I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.
> I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
> - uncompress the file jboss-ejb3.jar
> - delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
> - run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
> - recompress the jar
> This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 03:36:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
In-Reply-To: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10747830.1187076961065.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boris Maras updated EJBTHREE-1029:
----------------------------------

    Attachment: jboss-ejb3-client14.jar

This jar should work with JBoss 4.0.3SP1 and EJB3 RC6. It probably doesn't work for other versions of JBoss & EJB3.
It has been generated with the attached ant script.

> Invoke remote EJB3 from JVM 1.4 client
> --------------------------------------
>
>                 Key: EJBTHREE-1029
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
>             Project: EJB 3.0
>          Issue Type: Patch
>         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
> Client : JDK 1.4.2
>            Reporter: Boris Maras
>         Attachments: build-client1.4convert.xml, jboss-ejb3-client14.jar, patch build.xml ejb3-client1.4.txt
>
>
> Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.
> So I used jbossretro to convert this jar in jdk 1.4 compatible format.
> That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)
> In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
> - the client jar for your EJBs
> - the generated jboss-ejb3-client14.jar
> - jbossretro-rt.jar
> - jboss-backport-concurrent.jar
> - javassist.jar
> I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.
> I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.
> I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
> - uncompress the file jboss-ejb3.jar
> - delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
> - run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
> - recompress the jar
> This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:05:16 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Tue, 14 Aug 2007 04:05:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-145) bend points not
	displayed
Message-ID: <30921152.1187078716931.JavaMail.jira@cloud.prod.atl2.jboss.com>

bend points not displayed
-------------------------

                 Key: GPD-145
                 URL: http://jira.jboss.com/jira/browse/GPD-145
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
            Reporter: David Good
         Assigned To: Koen Aers


When opening an existing design in beta2 all existing bendpoints are ignored.  The bendpoints can be restored manually and saved,  but are not displayed when the design is re-opened.  If the design is opened in beta1, bendpoints are displayed as expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:12:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 04:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-145) bend points not
	displayed
In-Reply-To: <30921152.1187078716931.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3625367.1187079121071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-145?page=all ]

Koen Aers closed GPD-145.
-------------------------

    Resolution: Duplicate Issue

This is a duplicate of GPD-135 wich was fixed for the the 3.1.0.CR1 release.

> bend points not displayed
> -------------------------
>
>                 Key: GPD-145
>                 URL: http://jira.jboss.com/jira/browse/GPD-145
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
>            Reporter: David Good
>         Assigned To: Koen Aers
>
> When opening an existing design in beta2 all existing bendpoints are ignored.  The bendpoints can be restored manually and saved,  but are not displayed when the design is re-opened.  If the design is opened in beta1, bendpoints are displayed as expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:19:25 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 04:19:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-144) Renaming Task and
 Generating Form yields incorrect forms.xml
In-Reply-To: <28233236.1187040241261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19906397.1187079565590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-144?page=all ]

Koen Aers closed GPD-144.
-------------------------

    Resolution: Won't Fix

This bug can be worked around easily, I guess by first saving the name and then reopening the properties dialog. We will focus on fixing bugs on the 3.1.x branch and not on the 3.0.x branch as we don't have the resources and 3.1.x provides already a lot more functionality. 

> Renaming Task and Generating Form yields incorrect forms.xml
> ------------------------------------------------------------
>
>                 Key: GPD-144
>                 URL: http://jira.jboss.com/jira/browse/GPD-144
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.0.13
>         Environment: RHEL 5
> Eclipse 3.3
> Sun Java 1.5_12
>            Reporter: Micah Modell
>         Assigned To: Koen Aers
>
> If you create a new task on a TaskNode, rename it in the "General" tab and then use "Generate Form..." in the "Advanced" tab, the forms.xml entry references the original task name rather than the updated one.  This causes the jBPM admin console to be unable to find the task form.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:36:01 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 14 Aug 2007 04:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30182901.1187080561177.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371975 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

sure I will do, I am in meetings with one of our clients today, so this will probably be done tomorrow,

cheers

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Tue Aug 14 04:54:01 2007
From: jira-events at lists.jboss.org (Barry Knapp (JIRA))
Date: Tue, 14 Aug 2007 04:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13693642.1187081641605.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12371979 ] 
            
Barry Knapp commented on JBRULES-1020:
--------------------------------------

A filter for rules so the output is only the items that match would work well.

Here is a use case using 5 attributes of a rule:
1. Effective Date
2. Expiration Date
3. Test Effective Date
4. Test Expiration Date
5. Tested Status


There are 2 deployment types, one for deploying to test servers and one for production servers:

1.  Test Server : Users will create snapshot of rules to deploy to the Test Servers containing rules that meet the following criteria:

Test Effective Date >= Today
Test Expiration Date <= Today


2.  Production Server: Users will create snapshot of rules to deploy to the Production Servers containing rules that meet the following criteria:

Effective Date >=Today
Expiration Date >= Today
Tested Status = true



Justification: 
1.  Users must test new rules in the test servers, prior to moving them to production.
2.  Users must test the absence of rules in the test servers, prior to removing them from production.
3.  Users must test the replacement of rules in the test servers, such as when the logic of a rule is found to be incorrect and it is replaced by a new rule.


In my implementation I am always using the most recent version, so there is not much need for the historical search to meet this requirement.

___________________________________



> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Tue Aug 14 04:59:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 14 Aug 2007 04:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-573) Draw blocks with
 FLUSH (join & state transfer)
Message-ID: <10915282.1187081941172.JavaMail.jira@cloud.prod.atl2.jboss.com>

Draw blocks with FLUSH (join & state transfer)
----------------------------------------------

                 Key: JGRP-573
                 URL: http://jira.jboss.com/jira/browse/JGRP-573
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6
            Reporter: Bela Ban
         Assigned To: Vladimir Blagojevic
             Fix For: 2.6


To reproduce:
#1 Get the latest from CVS head
#2 Start 1 Draw: java org.jgroups.demos.Draw -props ./flush-udp.xml -state -use_blocking

- The flush-udp.xml config was copied from JGroups/conf and not modified
- use_blocking sets the Channel to use blocking

#3 Draw some points into Draw 
#4 Start a second instance of Draw
RESULT: the second instance does join correctly and also transfers the state correctly, but it hangs on FLUSH:

[linux]/home/bela$ draw -props ./flush-udp.xml -state -use_blocking

-------------------------------------------------------
GMS: address is 192.168.0.5:33755
-------------------------------------------------------
--  received BlockEvent
** View=[192.168.0.5:33754|1] [192.168.0.5:33754, 192.168.0.5:33755]
read state: 139 entries
-- received UnblockEvent
0 [WARN] [main] JChannel.connect(): 192.168.0.5:33755 waiting on UNBLOCK after connect timed 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 lists.jboss.org  Tue Aug 14 05:01:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 14 Aug 2007 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-573) Draw blocks with
 FLUSH (join & state transfer)
In-Reply-To: <10915282.1187081941172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30470815.1187082061168.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

This works if I don't use join&state, but call connect() and getState() in separate steps

> Draw blocks with FLUSH (join & state transfer)
> ----------------------------------------------
>
>                 Key: JGRP-573
>                 URL: http://jira.jboss.com/jira/browse/JGRP-573
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> To reproduce:
> #1 Get the latest from CVS head
> #2 Start 1 Draw: java org.jgroups.demos.Draw -props ./flush-udp.xml -state -use_blocking
> - The flush-udp.xml config was copied from JGroups/conf and not modified
> - use_blocking sets the Channel to use blocking
> #3 Draw some points into Draw 
> #4 Start a second instance of Draw
> RESULT: the second instance does join correctly and also transfers the state correctly, but it hangs on FLUSH:
> [linux]/home/bela$ draw -props ./flush-udp.xml -state -use_blocking
> -------------------------------------------------------
> GMS: address is 192.168.0.5:33755
> -------------------------------------------------------
> --  received BlockEvent
> ** View=[192.168.0.5:33754|1] [192.168.0.5:33754, 192.168.0.5:33755]
> read state: 139 entries
> -- received UnblockEvent
> 0 [WARN] [main] JChannel.connect(): 192.168.0.5:33755 waiting on UNBLOCK after connect timed 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 lists.jboss.org  Tue Aug 14 06:35:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 06:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25270039.1187087701140.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

There are two distinct major issues with the current client side failover info updating code:

1)
I download a connection factory
The network topology changes
I create a connection
The network topology is never updated on the client side

2)
I download a connection factory
The network topology changes such that none of the original nodes exist any more
I attempt to create a connection - this fails since none of the original nodes exist any more

The fundamental issue in the current implementation is that the updates are done on the *connection* - they should be done on the connection factory.

We need updates to happen even if there are no connections!!

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 07:01:13 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Tue, 14 Aug 2007 07:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7023201.1187089273411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen resolved JBAOP-449.
----------------------------------

    Resolution: Done

fixed by adding
<aoppaths>
  <aoppath></aoppath>
</aoppaths>
this makes it more multiplattform friendly..

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 07:01:13 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Tue, 14 Aug 2007 07:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-449) maven-jbossaop-plugin
 cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2199636.1187089273572.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen closed JBAOP-449.
--------------------------------


> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 07:08:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Aug 2007 07:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-450) AOP/MC Proxies do
 not include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21021140.1187089681366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-450?page=all ]

Kabir Khan updated JBAOP-450:
-----------------------------

    Attachment: test.zip

THe attached files illustrate the problem. Using javassist the annotations are there, but they are not picked up using the reflection api

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.beta
>
>         Attachments: test.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 lists.jboss.org  Tue Aug 14 07:14:01 2007
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Tue, 14 Aug 2007 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4606) Hypersonic server
 mode TCP socket problem
Message-ID: <5093937.1187090041430.JavaMail.jira@cloud.prod.atl2.jboss.com>

Hypersonic server mode TCP socket problem
-----------------------------------------

                 Key: JBAS-4606
                 URL: http://jira.jboss.com/jira/browse/JBAS-4606
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.2.0.GA
         Environment: Sun JVM, x86_64&i686, RHEL5, JBossAS conf. "default", running as service jbossas.
            Reporter: Martin Vecera
         Assigned To: Dimitris Andreadis


I wanted to deploy Duke's bank J2EE example. This requires HSQLDB in server mode. The server/deploy/hsqldb-ds.xml is well prepared for switching HSQLDB to server mode, so I did it. This XML file uses ${jboss.bind.address} property to determine HSQLDB binding address.

I was running JBossAS with 'service jbossas start'. In /etc/sysconfig/jbossas I had JBOSS_IP=127.0.0.1.
I got the following error:
2007-08-14 13:27:30,715 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)
        at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:179)
        at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
        at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
        at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
        at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
        at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
        at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
        at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
        at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
        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 org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        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 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 $Proxy42.start(Unknown Source)
        at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
        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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:508)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.sql.SQLException: socket creation error
        at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
        at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
        at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
        at org.hsqldb.jdbcDriver.connect(Unknown Source)
        at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
        ... 122 more

When I replaced the {$jboss.bind.address} (both occurences in hsqldb-ds.xml) with 'localhost' everything was OK.
So I tried to replace it with 127.0.0.1 and got the same error.
Then I tried to put the ${jboss.bind.address} property back and changed JBOSS_IP in /etc/sysconfig/jbossas to 'localhost'.
Well, everything was working then.
So I returned JBOSS_IP=127.0.0.1 back and voila - everything is OK!!!
I tried it twice on two different machines. Once I used JBOSS_IP=localhost I was able to use any of the previously mentioned configuration and it was working. VERY STRANGE! After each change I restarted JBossAS completely.

I tried nslookup at the beginning to see if it is bound corectly:
[root at xen61 deploy]# nslookup 127.0.0.1
Server:         10.34.32.125
Address:        10.34.32.125#53

1.0.0.127.in-addr.arpa  name = localhost.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 07:44:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 07:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1569) Adding window
 properties
 with names starting with one of the letters from the range 'a-t'
In-Reply-To: <5795348.1184142571904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30026003.1187091841499.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1569.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

Resolved, thanks for reporting this issue !

> Adding window properties with names starting with one of the letters from the range 'a-t'
> -----------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1569
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1569
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 Final
>            Reporter: Pavel Myshkin
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> When trying to add a window property of some window with the key name starting with letters a-s (upper or lower) you get an exception:
>  Cause: javax.portlet.PortletException: Expected submitted value of type Boolean for Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /WEB-INF/jsf/editProperties.xhtml][Class: javax.faces.component.html.HtmlForm,Id: _id55jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj][Class: javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: _id111jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj]}
> Message: Expected submitted value of type Boolean for Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /WEB-INF/jsf/editProperties.xhtml][Class: javax.faces.component.html.HtmlForm,Id: _id55jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj][Class: javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: _id111jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj]}
> StackTrace:
> javax.portlet.PortletException: Expected submitted value of type Boolean for Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /WEB-INF/jsf/editProperties.xhtml][Class: javax.faces.component.html.HtmlForm,Id: _id55jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj][Class: javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: _id111jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj]}
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:253)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:399)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
> 	at org.jboss.portal.faces.portlet.JSFMetaBridgePortlet.render(JSFMetaBridgePortlet.java:125)
> ......
> This does not happen with properties that the key starts with letters t-z.
> looks like it is somehow linked to the alphabetical position of the added key in relation to already existing window properties "Partial refresh" and "Region order". The key names that produced the exception are located before these properties in the list and the ones that did not generate the exception are located after these native 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 lists.jboss.org  Tue Aug 14 08:58:01 2007
From: jira-events at lists.jboss.org (Mike Khlu (JIRA))
Date: Tue, 14 Aug 2007 08:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-68) assert
 collection.remove(this) is fail
Message-ID: <28339829.1187096281133.JavaMail.jira@cloud.prod.atl2.jboss.com>

assert collection.remove(this) is fail
--------------------------------------

                 Key: HIBERNATE-68
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-68
             Project: Hibernate
          Issue Type: Task
            Reporter: Mike Khlu
         Assigned To: Steve Ebersole
            Priority: Minor


I've got simple ManyToMany case

class A {
  @ManyToMany
  Set<B> bes=...;
}

class B {
  @ManyToMany(mappedBy="bes")
  Collection<A> aes=...;

  void addAssociation(A newbie){
   // everything is clear. and works well
   ....
  }
  void removeAssociation(A associated){
     assert aes.remove(associated); // works fine
     assert a.bes.remove(this);   // doesn't works !!!
  }
}

if you try to run simple "exploit", you would be unhappy 

void foo(){
  A a = .... // gets poxy from session
  B b = a.iterator().next(); // gets proxy of associated entity by association

  b.removeAssociation(a); // we'll got a fail
} 

Of course, I know the cause:
1. method call would be delegated to entity (target) by proxy
2. so, "this" in method body means entity (target) not a proxy
3. We can't find entity in collection of proxies, in spite of we have proxy with such ID there

What do you think about 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 lists.jboss.org  Tue Aug 14 09:02:16 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Tue, 14 Aug 2007 09:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
Message-ID: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException after adding a google portlet to dashboard
---------------------------------------------------------------

                 Key: JBPORTAL-1629
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.8 Final
            Reporter: Roman Kalyakin
         Assigned To: Julien Viet
         Attachments: JBPORTAL-1629.patch

When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:02:17 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Tue, 14 Aug 2007 09:02:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21352647.1187096537037.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Roman Kalyakin updated JBPORTAL-1629:
-------------------------------------

    Attachment: JBPORTAL-1629.patch

This patch seems to fix the problem. 

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Julien Viet
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:05:01 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Tue, 14 Aug 2007 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25059594.1187096701235.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1629?page=comments#action_12372007 ] 
            
Roman Kalyakin commented on JBPORTAL-1629:
------------------------------------------

A patch in attachment seems to fix the problem. It was introduced recently by adding a PortalAuthorizationManagerFactory property.

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Julien Viet
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:11:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 14 Aug 2007 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4607) Transaction timeout
 is not
 raising a JMSException in the JBossMQ Persistence manager or StateManager
Message-ID: <9458837.1187097061643.JavaMail.jira@cloud.prod.atl2.jboss.com>

Transaction timeout is not raising a JMSException in the JBossMQ Persistence manager or StateManager
----------------------------------------------------------------------------------------------------

                 Key: JBAS-4607
                 URL: http://jira.jboss.com/jira/browse/JBAS-4607
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


In JBossMQ, if something other than the jdbc2 PersistenceManager or StateManager
marks a transaction as "setRollbackOnly", e.g. a transaction timeout
then they both silently rollback the exception without throwing an Exception.

An Exception should be thrown to tell the caller that the operation 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 lists.jboss.org  Tue Aug 14 09:15:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 09:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1621) "title"
 attribute of "link" tag in jboss-portlet.xml is unhandled
In-Reply-To: <30538884.1186386229579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5659511.1187097301875.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1621.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

> "title" attribute of "link" tag in jboss-portlet.xml is unhandled
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-1621
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1621
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>         Environment: JBoss Portal 2.6.1 GA bundled
>            Reporter: Pavel Myshkin
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> JBOSS-PORTLET.XML
> --------------------------------
> <!DOCTYPE portlet-app PUBLIC
>    "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
>    "dtd/jboss-portlet_2_6.dtd">
> <portlet-app>
> <portlet>
> <portlet-name>PortletName</portlet-name>
> <header-content>
> <!-- main calendar program -->
> <link rel="stylesheet" type="text/css" media="all" href="/calendar-win2k-cold-1.css"  title="win2k-cold-1"/>
> </header-content>
> </portlet>
> </portlet-app>
> Generates an error :
> Caused by: org.xml.sax.SAXException: Attribute "title" must be declared for element type "link". @ *unknown*[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 lists.jboss.org  Tue Aug 14 09:19:20 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:19:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-146) improve feedback when
 creating self referencing transitions
Message-ID: <14993915.1187097560953.JavaMail.jira@cloud.prod.atl2.jboss.com>

improve feedback when creating self referencing transitions
-----------------------------------------------------------

                 Key: GPD-146
                 URL: http://jira.jboss.com/jira/browse/GPD-146
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
    Affects Versions: jBPM JPDL Designer 3.1.0.GA
            Reporter: Koen Aers
         Assigned To: Koen Aers
            Priority: Minor


At the moment creating self referencing transitions is done by clicking twice on the source/target node. In the future some feedback (a dummy transition) should make this proces more obvious

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:21:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-24) add convenient way to
 create loop transitions
In-Reply-To: <28729967.1168955216880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28897891.1187097661065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-24?page=all ]

Koen Aers closed GPD-24.
------------------------

    Resolution: Done

I am closing this as it is now possible to create loop transitions by clicking twice on the source/target node. However GPD-146 was created because there are still improvements possible

> add convenient way to create loop transitions
> ---------------------------------------------
>
>                 Key: GPD-24
>                 URL: http://jira.jboss.com/jira/browse/GPD-24
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> the current workaround is to write the self-transition in xml.
> but this results in some *really* weird bendpoints when going back to the graphical 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 lists.jboss.org  Tue Aug 14 09:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-146) improve feedback when
 creating self referencing transitions
In-Reply-To: <14993915.1187097560953.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24971774.1187097781277.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-146?page=all ]

Koen Aers updated GPD-146:
--------------------------

    Component/s: jpdl

> improve feedback when creating self referencing transitions
> -----------------------------------------------------------
>
>                 Key: GPD-146
>                 URL: http://jira.jboss.com/jira/browse/GPD-146
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.GA
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Minor
>
> At the moment creating self referencing transitions is done by clicking twice on the source/target node. In the future some feedback (a dummy transition) should make this proces more obvious

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-143) Load the icon of a
 paletteContribution entry from the plugin directory where it is defined
In-Reply-To: <28132773.1186761253835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27215768.1187097781753.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-143?page=all ]

Koen Aers updated GPD-143:
--------------------------

    Component/s: jpdl

> Load the icon of a paletteContribution entry from the plugin directory where it is defined
> ------------------------------------------------------------------------------------------
>
>                 Key: GPD-143
>                 URL: http://jira.jboss.com/jira/browse/GPD-143
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>
> In PaletteRoot class, the icon of a palette entry is always loaded from org.jbpm.gd.jpdl plugin, even if the paletteContribution entry is defined in a dependent plugin.
> The information, where the palette entry element (entryElement in PaletteRoot.addControls) is defined, can be found in entryElement.getContributor().getName().
> So also the corresponding image can be loaded from the correct bundle.
> [ Sorry to only give a verbal description of the implementation. I would sign a corporate contributor's agreement, but I have problems with the procedure, e.g.
> - do we need a corporate jboss account for my boss to sign
> - if we sign with the "corporate" account, with which account I need to contribute then
> etc.
> So I would need some assistance here. Then you would get a real diff also.
> ]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:40:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 14 Aug 2007 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4607) Transaction timeout
 is not raising
 a JMSException in the JBossMQ Persistence manager or StateManager
In-Reply-To: <9458837.1187097061643.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32026233.1187098801048.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Adrian Brock closed JBAS-4607.
------------------------------

    Resolution: Done

Done. The fix is relatively trivial.

It involves only rolling back when we know there is an error
(we don't want to mask the real error if we know it)
i.e. something invoked setRollbackOnly on the TMS or Session.
otherwise we try to commit, which will raise an error if it timed out.

> Transaction timeout is not raising a JMSException in the JBossMQ Persistence manager or StateManager
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4607
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4607
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> In JBossMQ, if something other than the jdbc2 PersistenceManager or StateManager
> marks a transaction as "setRollbackOnly", e.g. a transaction timeout
> then they both silently rollback the exception without throwing an Exception.
> An Exception should be thrown to tell the caller that the operation 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 lists.jboss.org  Tue Aug 14 09:50:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26793975.1187099401189.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1629.
------------------------------------

    Fix Version/s: 2.6.2 Final
       Resolution: Done
         Assignee: Thomas Heute  (was: Julien Viet)

Thanks a lot !

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:50:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2643386.1187099401350.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1629:
-----------------------------------

    Fix Version/s: 2.8 Final

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 10:06:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1294)
 JBP_CMS_WSP_PROP.PK unique contraint violated
In-Reply-To: <10327003.1172555376394.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9655904.1187100361987.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1294.
------------------------------------

    Resolution: Cannot Reproduce Bug
      Assignee: Thomas Heute

As mark it as "Cannot reproduce bug" unless you have a way to reproduce it.

> JBP_CMS_WSP_PROP.PK unique contraint violated
> ---------------------------------------------
>
>                 Key: JBPORTAL-1294
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1294
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.Alpha2
>         Environment: AS 4.0.5.GA
> Oracle 9i
>            Reporter: Ian White
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Try to create a content item using the CMS Admin Portlet.
> Get oracle sql exception - primary key unique contraint violated - JBP_CMS_SWP_PROP.PK:
> 16:32:14,171 INFO  [Http11BaseProtocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-80
> 16:32:14,328 INFO  [ChannelSocket] JK: ajp13 listening on /0.0.0.0:9
> 16:32:14,343 INFO  [JkMain] Jk running ID=0 time=0/78  config=null
> 16:32:14,359 INFO  [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 1m:12s:797ms
> 16:32:57,671 WARN  [JDBCExceptionReporter] SQL Error: 1, SQLState: 23000
> 16:32:57,671 ERROR [JDBCExceptionReporter] ORA-00001: unique constraint (JBPORTAL26.SYS_C0032370) violated
> 16:32:57,671 WARN  [JDBCExceptionReporter] SQL Error: 1, SQLState: 23000
> 16:32:57,671 ERROR [JDBCExceptionReporter] ORA-00001: unique constraint (JBPORTAL26.SYS_C0032370) violated
> 16:32:57,671 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
> org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
>         at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
>         at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
>         at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
>         at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
>         at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
>         at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
>         at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:41)
>         at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:969)
>         at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1114)
>         at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.loadManagedNode(PortalCMSCacheLoader.java:757)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.saveWSPPropNodeEntry(PortalCMSCacheLoader.java:560)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.put(PortalCMSCacheLoader.java:305)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.put(PortalCMSCacheLoader.java:389)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.prepare(PortalCMSCacheLoader.java:479)
>         at org.jboss.cache.interceptors.CacheStoreInterceptor.prepareCacheLoader(CacheStoreInterceptor.java:296)
>         at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:130)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
>         at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
>         at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
>         at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1491)
>         at org.jboss.tm.TransactionImpl.beforePrepare(TransactionImpl.java:1110)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:324)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
>         at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.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 lists.jboss.org  Tue Aug 14 10:06:02 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Tue, 14 Aug 2007 10:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-573) Draw blocks with
 FLUSH (join & state transfer)
In-Reply-To: <10915282.1187081941172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24332240.1187100362574.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic resolved JGRP-573.
--------------------------------------

    Resolution: Done

Resolved. Change set:
JChannel.java 1.141 --> 1.142

> Draw blocks with FLUSH (join & state transfer)
> ----------------------------------------------
>
>                 Key: JGRP-573
>                 URL: http://jira.jboss.com/jira/browse/JGRP-573
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> To reproduce:
> #1 Get the latest from CVS head
> #2 Start 1 Draw: java org.jgroups.demos.Draw -props ./flush-udp.xml -state -use_blocking
> - The flush-udp.xml config was copied from JGroups/conf and not modified
> - use_blocking sets the Channel to use blocking
> #3 Draw some points into Draw 
> #4 Start a second instance of Draw
> RESULT: the second instance does join correctly and also transfers the state correctly, but it hangs on FLUSH:
> [linux]/home/bela$ draw -props ./flush-udp.xml -state -use_blocking
> -------------------------------------------------------
> GMS: address is 192.168.0.5:33755
> -------------------------------------------------------
> --  received BlockEvent
> ** View=[192.168.0.5:33754|1] [192.168.0.5:33754, 192.168.0.5:33755]
> read state: 139 entries
> -- received UnblockEvent
> 0 [WARN] [main] JChannel.connect(): 192.168.0.5:33755 waiting on UNBLOCK after connect timed 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 lists.jboss.org  Tue Aug 14 10:10:02 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 14 Aug 2007 10:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16318807.1187100602640.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372028 ] 
            
Paul Gier commented on JBAOP-453:
---------------------------------


I think it's fine to specify dependencies of the plugin in the plugin's pom.xml.  If these dependencies (jboss-aop, plexus-utils, etc) are required to compile and run the plugin then they should be in the plugin pom.xml.  These dependencies will only be used by the client at build time.  If some of them are required at runtime, then the client project should specify the dependencies in it's own pom.xml in a runtime or compile scope.

If the client requires additional dependencies to run the plugin, then those can be defined as dependencies of the plugin in the client pom.
Unfortunately, maven doesn't allow you to exclude (and redifine) plugin dependencies like you can with regular transitive dependencies.  By putting the client defined plugin dependencies first in the forked classpath, that should allow you to override which version of jboss-aop the plugin uses.  I think this is similar to what you suggested in number 2.

Which dependencies are you talking about moving?  It seems like it would be more difficult for the user if the plugin doesn't have it's own default dependencies defined.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Tue Aug 14 10:10:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 14 Aug 2007 10:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1026) Refactor
 extended persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19336434.1187100602900.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf updated EJBTHREE-1026:
------------------------------------

    Priority: Critical  (was: Major)

> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Tue Aug 14 10:28:02 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 10:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8941760.1187101682214.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=comments#action_12372033 ] 
            
Joe Son commented on JBRULES-1081:
----------------------------------

I've moved the contents of the extracted standalone version to my C drive. (Windows env). Had to add additional env. variable (JAVA_HOME2) and modify all the config files to point to it. (Catalina, setup, setclass etc). 

I'm wondering if there was data corruption because the server did not start properly the first time? I had to stop and restart several times before I got the configuration right.

Hope this helps.

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 10:52:08 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 10:52:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1042) Investigate
 possible casting issue with message bridge
In-Reply-To: <5137497.1186667449514.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1636508.1187103128793.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1042.
--------------------------------

    Resolution: Done

> Investigate possible casting issue with message bridge
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1042
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1042
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>         Attachments: JBMESSAGING-1042.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 lists.jboss.org  Tue Aug 14 10:57:01 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 10:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8923435.1187103421188.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=comments#action_12372040 ] 
            
Joe Son commented on JBRULES-1081:
----------------------------------

I've installed new copy of the standalone version. (Got Rid of old one).
I've found that Xalan jar file is missing from the Standalone version.  I've removed existing repository directory and xml file in an effort to make sure the entire process works. (i.e. starting the server should create the directory if it doesn't exists)

I've also modified all batch files to make sure they point to new java home with JDK1.5. Previously I missed it on few batch files.  This seem to work for most part. I'm still having issues with being able to access all parts of BRMS.  I feel like there are still configuration issues to be resolved.  

1. Logout points to 404 page.  This maybe redirect setting issue? 
2. Accessing cerntain DRL file returns error.
3. Still Not sure how to set up logging.properites file to generate error log on localhost.<date> file.

Any comments or questions?

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:10:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-983) Messages can
 be delivered after connection is stopped
In-Reply-To: <20962966.1181209274478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16274461.1187104201431.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-983:
--------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Messages can be delivered after connection is stopped
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-983
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-983
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> Stopping a connection does not currently block until all current onMessage invocations are complete, as per JMS spec.
> We need to make sure it 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 lists.jboss.org  Tue Aug 14 11:12:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1036) Consider
 createing JBossDestination interface
In-Reply-To: <10696945.1186598809453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12586267.1187104321265.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1036.
--------------------------------

    Resolution: Won't Fix

Seems like a Spring bug.

> Consider createing JBossDestination interface
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1036
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1036
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> To solve forum 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 lists.jboss.org  Tue Aug 14 11:12:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-908) MySQL on Linux
 fails to load server after failover
In-Reply-To: <21443708.1172746149080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22805949.1187104321878.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-908.
-------------------------------

    Resolution: Won't Fix

Am 99.9% sure this is due to using a non transacted datastore so closing.

> MySQL on Linux fails to load server after failover
> --------------------------------------------------
>
>                 Key: JBMESSAGING-908
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-908
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Sometimes, after failover occurs and a server is restarted, the server start fails with:
> java.lang.IllegalStateException: Did not load correct number of messages, wanted:1 but got:0
> 	at org.jboss.messaging.core.PagingChannelSupport.processReferences(PagingChannelSupport.java:591)
> 	at org.jboss.messaging.core.PagingChannelSupport.doLoad(PagingChannelSupport.java:518)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.LocalClusteredQueue.mergeIn(LocalClusteredQueue.java:243)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.performFailover(DefaultClusteredPostOffice.java:2169)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.nodeLeft(DefaultClusteredPostOffice.java:2031)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.access$1800(DefaultClusteredPostOffice.java:98)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$HandleViewAcceptedRunnable.run(DefaultClusteredPostOffice.java:2400)
> 	at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
> 	at java.lang.Thread.run(Thread.java:595
> or similar.
> Analysing logs it seems this is because when the server crashed previously it did so and partially committed a transaction, i.e inserted the ref but not the message.
> My suspicion is that this is because the MySQL configuration being used is setup to use the non transaction myISAAM storage which has no transaction  support. But this needs to be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:12:02 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-838) Test scenario
 where no failover has occurred on server side...
In-Reply-To: <4920923.1171498965960.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25143347.1187104322147.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-838:
--------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Test scenario where no failover has occurred on server side...
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-838
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-838
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.2.0.Beta2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Optional
>             Fix For: 2.0.0 Beta 1
>
>
> When a client thinks the server has failed e.g. the netwrk between client--server temporarily fails but the network between server--server is ok, the server will return -1 to say no failover is occurring or times out then the client will retry the orginal node after a pause.
> The pause needs to be made configurable and a test devised to test this 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 lists.jboss.org  Tue Aug 14 11:16:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 14 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27189207.1187104561361.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic reassigned JBMESSAGING-1027:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:16:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 14 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-574) UnicastChannelTest
	doesn't work
Message-ID: <8228116.1187104561702.JavaMail.jira@cloud.prod.atl2.jboss.com>

UnicastChannelTest doesn't work
-------------------------------

                 Key: JGRP-574
                 URL: http://jira.jboss.com/jira/browse/JGRP-574
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


Messages are not received 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:24:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 11:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-81) Add support for
 reconnecting transitions
In-Reply-To: <898355.1178879092359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23117778.1187105041738.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-81?page=all ]

Koen Aers closed GPD-81.
------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

A small present for christmas for Ronald ;-)

> Add support for reconnecting transitions
> ----------------------------------------
>
>                 Key: GPD-81
>                 URL: http://jira.jboss.com/jira/browse/GPD-81
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: Clean eclipse 3.2.2 and gpd 3.1alpha4
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> Not being able to reconnect transitions graphically from e.g. node a to node b is still a big omission for the gpd to be used by 'grey suites' as well as 'jeans and t-shirts', at least within our company. I thought there was a long standing issue for this, but I cannot find it. 
> If someone could point me to a place to start looking into this, I'd be happy to try to implement this (but it will be the only gpd thing I 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 lists.jboss.org  Tue Aug 14 11:58:10 2007
From: jira-events at lists.jboss.org (no way (JIRA))
Date: Tue, 14 Aug 2007 11:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1082) minor changes to
 the drools documentation
Message-ID: <15164549.1187107090966.JavaMail.jira@cloud.prod.atl2.jboss.com>

minor changes to the drools documentation
-----------------------------------------

                 Key: JBRULES-1082
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1082
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.GA
            Reporter: no way
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


In the documentation [ver 4.0.0]
[not using the numbering because latest version -> different numbering]
===================
chapter :
The rule language 
    -> Rule
        -->Left Hand Side Conditional Elements
            ->operators
misspelled operator :  in the documentation memberof is used, whilst in drools memberOf should be used [case thingie]

====================
chapter :
The rule language 
    -> Rule
        -->Left Hand Side Conditional Elements
            ->> forall

example : combining forall with Not CE
in own testing the not forall  like used in the example doesnt seem to work
when adding parenthesis the problem is resolved
i.e.
when
   not (  <- add this one
            forall (things_here)
          ) <- add this 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 lists.jboss.org  Tue Aug 14 12:23:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-190) webservice
 descriptors generation tool
Message-ID: <26672132.1187108581255.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-190?page=all ]

Alejandro Guizar updated BPEL-190:
----------------------------------

    Summary: webservice descriptors generation tool  (was: web app generation tool)

> webservice descriptors 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.2 GA
>
>
> 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 lists.jboss.org  Tue Aug 14 12:27:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 14 Aug 2007 12:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1038) Client side
 failover hopping does not work
In-Reply-To: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23200347.1187108821549.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic reassigned JBMESSAGING-1038:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Client side failover hopping does not work
> ------------------------------------------
>
>                 Key: JBMESSAGING-1038
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.
> if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".
> Instead it should iterate through the list of delegates trying each one in turn.
> Need to write a test for this 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 lists.jboss.org  Tue Aug 14 12:44:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 14 Aug 2007 12:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-4532) Track JBoss and
 thirdparty dependencies for JBossAS 4.4.x
Message-ID: <20912203.1187109841271.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis deleted JBAS-4532:
-------------------------------------


> Track JBoss and thirdparty dependencies for JBossAS 4.4.x
> ---------------------------------------------------------
>
>                 Key: JBAS-4532
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4532
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>
> Parent task to track jboss and thirdparty library dependencies/upgrades for JBossAS 4.4.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 lists.jboss.org  Tue Aug 14 12:52:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-218) make the imported
 wsdl documents a source of partner service descriptions
In-Reply-To: <17113795.1166408025580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25884971.1187110321145.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-218?page=all ]

Alejandro Guizar updated BPEL-218:
----------------------------------

        Summary: make the imported wsdl documents a source of partner service descriptions  (was: use imported documents as a service catalog)
    Description: Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.  (was: Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in trivial scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner information is the list of imported documents.)

> make the imported wsdl documents a source of partner service descriptions
> -------------------------------------------------------------------------
>
>                 Key: BPEL-218
>                 URL: http://jira.jboss.com/jira/browse/BPEL-218
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.2 GA
>
>
> Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 12:56:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-275) web module deployment
	tool
Message-ID: <8332987.1187110561120.JavaMail.jira@cloud.prod.atl2.jboss.com>

web module deployment tool
--------------------------

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


Develop a tool for deploying web modules to the application server. Use JSR-88 APIs if possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 12:58:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-275) web module deployment
	tool
In-Reply-To: <8332987.1187110561120.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9146206.1187110681430.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-275?page=all ]

Alejandro Guizar updated BPEL-275:
----------------------------------

     Original Estimate: 1 week
    Remaining Estimate: 1 week

> web module deployment tool
> --------------------------
>
>                 Key: BPEL-275
>                 URL: http://jira.jboss.com/jira/browse/BPEL-275
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Develop a tool for deploying web modules to the application server. Use JSR-88 APIs if possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:00:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 13:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-218) make the imported
 wsdl documents a source of partner service descriptions
In-Reply-To: <17113795.1166408025580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23753667.1187110801392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-218?page=all ]

Alejandro Guizar updated BPEL-218:
----------------------------------

     Original Estimate: 3 days
    Remaining Estimate: 3 days

> make the imported wsdl documents a source of partner service descriptions
> -------------------------------------------------------------------------
>
>                 Key: BPEL-218
>                 URL: http://jira.jboss.com/jira/browse/BPEL-218
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.2 GA
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:02:01 2007
From: jira-events at lists.jboss.org (Przemyslaw Dej (JIRA))
Date: Tue, 14 Aug 2007 13:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-165) Nukes forums to
 JBoss Forums migration scripts
In-Reply-To: <30384231.1169689014154.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1229054.1187110921930.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Przemyslaw Dej resolved JBFORUMS-165.
-------------------------------------

    Resolution: Done

> Nukes forums to JBoss Forums migration scripts
> ----------------------------------------------
>
>                 Key: JBFORUMS-165
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-165
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum Model Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Przemyslaw Dej
>            Priority: Blocker
>             Fix For: 1.1.0 Alpha
>
>          Time Spent: 1 week, 2 days
>
> We need to update migration scripts and test them properly. Later we should make them available in JBoss Forums downloads in migration category. Plus a small instruction how to use them in the guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:06:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Aug 2007 13:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4608) Consider adding
 FLUSH to channels in Branch_4_x
Message-ID: <21081239.1187111161233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Consider adding FLUSH to channels in Branch_4_x
-----------------------------------------------

                 Key: JBAS-4608
                 URL: http://jira.jboss.com/jira/browse/JBAS-4608
             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.2.2.GA


David Ward experienced problems with virtual synchrony in demo apps he was running on 4.2.1.GA.  These were resolved by adding FLUSH to the cluster-service.xml stack.  Need to consider whether we should add FLUSH to the standard stacks in 4.2.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 lists.jboss.org  Tue Aug 14 13:16:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Aug 2007 13:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4608) Consider adding
 FLUSH to channels in Branch_4_x
In-Reply-To: <21081239.1187111161233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13269997.1187111761320.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry updated JBAS-4608:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116104

> Consider adding FLUSH to channels in Branch_4_x
> -----------------------------------------------
>
>                 Key: JBAS-4608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4608
>             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.2.2.GA
>
>
> David Ward experienced problems with virtual synchrony in demo apps he was running on 4.2.1.GA.  These were resolved by adding FLUSH to the cluster-service.xml stack.  Need to consider whether we should add FLUSH to the standard stacks in 4.2.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 lists.jboss.org  Tue Aug 14 13:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 13:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1024) Distributed
 queue stops working when node is killed
In-Reply-To: <3119231.1186596736249.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29104460.1187111881899.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1024.
--------------------------------

    Resolution: Done

> Distributed queue stops working when node is killed
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1024
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1024
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> If start a test with 3 nodes, then kill one of them then the distributed queue doesn't work.
> Try starting DistributedRequestResponseTest with 3 nodes then killing to replicate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:34:01 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Aug 2007 13:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
In-Reply-To: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22285485.1187112841107.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Stan Silvert resolved JBAS-4605.
--------------------------------

    Fix Version/s: JBossAS-4.2.2.GA
       Resolution: Done

Added this to web.xml:

<init-param>
         <param-name>compilerSourceVM</param-name>
         <param-value>1.5</param-value>
</init-param>


> JSP compiler won't compile JDK 1.5 source
> -----------------------------------------
>
>                 Key: JBAS-4605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>             Fix For: JBossAS-4.2.2.GA
>
>
> From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:40:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 13:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1025) Add test in
 GroupManagementTest
In-Reply-To: <24748680.1186597189354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1768455.1187113201090.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-1025:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Add test in GroupManagementTest
> -------------------------------
>
>                 Key: JBMESSAGING-1025
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1025
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> .... that tests that failover map is created in vew order

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:04:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Tue, 14 Aug 2007 16:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29403184.1187121841140.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-449?page=comments#action_12372120 ] 
            
Anders Andersen commented on JBAOP-449:
---------------------------------------

1) I have testet the multiple aoppaths by

              <aoppaths>
                <aoppath>
                  ${basedir}/../jboss-portal-sar/src/main/resources/portal-aop.xml 
                </aoppath>
                <aoppath>
                  ${basedir}/src/main/resources/base-aop.xml
                </aoppath>
              </aoppaths>

AND IT WORKS !!!!

2) At the same time I have testet the default...

      else
         return "src/main/resources/jboss-aop.xml";

IT DOES NOT WORK
The problem is process current directory. If it is inside the maven module it works if it is outside it does not work
And for any larger build it will be outside !!!!

There has to be put ${basedir} in front of it.
Code like
      else
         return new File(project.getBasedir(),"src/main/resources/jboss-aop.xml").getName();






> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 16:06:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Tue, 14 Aug 2007 16:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26871065.1187121961302.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Anders Andersen reopened JBAOP-449:
-----------------------------------

             
${basedir} must be added to the default.

      else
         return new File(project.getBasedir(),"src/main/resources/jboss-aop.xml").getName();

(my code sample is not testet!!!)

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 16:08:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Aug 2007 16:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4554) Extract clustering
 stuff from
 testsuite/build.xml into imports/config/tests-clustering.xml
In-Reply-To: <23944399.1184513043676.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <891438.1187122081367.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry closed JBAS-4554.
----------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                       (was: JBossAS-5.0.0.CR1)
       Resolution: Done

> Extract clustering stuff from testsuite/build.xml into imports/config/tests-clustering.xml
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4554
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Optional
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> A la what Anil did for tests-jacc in Branch_4_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 lists.jboss.org  Tue Aug 14 16:25:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Tue, 14 Aug 2007 16:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2290054.1187123101553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

John Ruud updated GPD-78:
-------------------------


Koen,

This now appears to work for me!

Thanks, John

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Tue Aug 14 16:33:08 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 16:33:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7629856.1187123588083.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=comments#action_12372126 ] 
            
Joe Son commented on JBRULES-1081:
----------------------------------

Hey Guys, you can close this particular bug.
This was all configuration.
If anyone is trying to run this and having issues, please make sure all your batch files are pointing to correct java home.  In Window's env, you may want to create secondary env and point it to JDK1.5.

Other issues with Standalone I've come across was client side javascript error and logout redirect issues.
Not sure if these are configuration or not.

thank you.

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:33:08 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 16:33:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15933953.1187123588232.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Joe Son updated JBRULES-1081:
-----------------------------

    Priority: Minor  (was: Major)

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>            Priority: Minor
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:37:01 2007
From: jira-events at lists.jboss.org (Hany Mesha (JIRA))
Date: Tue, 14 Aug 2007 16:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3982)
 HASingletonController emits a
 cluster-wide JMX Notification after starting/stopping singleton
In-Reply-To: <26865730.1168626292592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13238544.1187123821709.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Hany Mesha reassigned JBAS-3982:
--------------------------------

    Assignee: Hany Mesha  (was: Brian Stansberry)

> HASingletonController emits a cluster-wide JMX Notification after starting/stopping singleton
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3982
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3982
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Hany Mesha
>             Fix For: JBossAS-5.0.1.CR1
>
>
> Provide a mechanism for cluster-wide notifications when singleton services are started and stopped.
> In conjunction with this, a special BarrierController variant could be developed that monitors the cluster-wide notifications, allowing service dependencies on remote singletons.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:37:02 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 16:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13345403.1187123822033.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12372128 ] 
            
Koen Aers commented on GPD-78:
------------------------------

Thanks John, I'll close the issue and get ready for the GA release!

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Tue Aug 14 16:37:02 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 16:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3667268.1187123822722.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers closed GPD-78.
------------------------

    Resolution: Done

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Tue Aug 14 16:54:14 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 16:54:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1032) Problem with
 bridge when source is remote
In-Reply-To: <25187402.1186598044726.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13744576.1187124854446.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1032.
--------------------------------

    Resolution: Rejected

Looks like user error.

Remote JMS provider needs to be configured to use global JNDI namespace

> Problem with bridge when source is remote
> -----------------------------------------
>
>                 Key: JBMESSAGING-1032
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1032
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Need to investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 17:02:02 2007
From: jira-events at lists.jboss.org (Steven Holmes (JIRA))
Date: Tue, 14 Aug 2007 17:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10458228.1187125322322.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12372139 ] 
            
Steven Holmes commented on JBPORTAL-1626:
-----------------------------------------

I think this is the same issue:

13:52:45,052 ERROR [DefaultPageControlPolicy] Rendering portlet window  produced an error
java.lang.NullPointerException
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:235)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$Transactio
nInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNe
xt(TransactionInterceptor$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNe
xt(TransactionInterceptor$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNe
xt(TransactionInterceptor$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchr
onizationInterceptor.java:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherIntercept
or.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        at sun.reflect.GeneratedMethodAccessor351.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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.jav
a:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$Prod
ucerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(Produc
erPortletInvoker$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(Produc
erPortletInvoker$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(Produc
erPortletInvoker$invoke_N8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService
.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerServi
ce.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManageme
ntInterceptorImpl.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchron
izationInterceptor.java:116)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$Ins
tanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(Instan
ceContainerImpl$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(Instan
ceContainerImpl$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(Instan
ceContainerImpl$invoke_N8654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:24
0)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericC
ontentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105
)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.
java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)

        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.jav
a:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.jav
a:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor
.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.
java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)

        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.jav
a:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.jav
a:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor
.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHan
dler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:7
9)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler
.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelect
or.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.jav
a:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerIntercepto
r.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionI
nterceptor$invoke$aop(TransactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(Transactio
nInterceptor$invoke_N5143606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(Transactio
nInterceptor$invoke_N5143606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(Transactio
nInterceptor$invoke_N5143606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)



> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 17:06:06 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Tue, 14 Aug 2007 17:06:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
Message-ID: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>

Brackets are not always optional for non-existential quantifier "not" 
----------------------------------------------------------------------

                 Key: JBRULES-1083
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Markus Reitz
         Assigned To: Mark Proctor
            Priority: Minor


According to the documentation, brackets are optional as illustrated by

  Example 6.37. No Busses

  not Bus()

In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)

  package test

  rule "Brackets"

    when
      not exists(x : SpecialString() and
                 forall(y : SpecialString(this!=x)
                            SpecialString(this==y, text=="Universe")))

    then
      System.out.println("Condition satisfied");
  end

this is not true. Trying to load this rule leads to

org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
at org.drools.rule.Package.checkValidity(Package.java:408)
at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
at DroolsTest.<init>(Unknown Source)
at DroolsTest.main(Unknown Source)

When brackets are added:

  package test

  rule "Brackets"

    when
      not(exists(x : SpecialString() and
                 forall(y : SpecialString(this!=x)
                            SpecialString(this==y, text=="Universe"))))

    then
      System.out.println("Condition satisfied");
  end

rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 17:08:01 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 14 Aug 2007 17:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
Message-ID: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>

Removing elements directly from source editor doesnt update the model and adater
--------------------------------------------------------------------------------

                 Key: GPD-147
                 URL: http://jira.jboss.com/jira/browse/GPD-147
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:

public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
		if (changedFeature != null) {
			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
		} else if (INodeNotifier.ADD == eventType) {
			handleDomAdd(newValue);
		} else if (INodeNotifier.REMOVE == eventType) {
			handleDomRemove(oldValue);
		}
	}

When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 17:46:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17707806.1187127961666.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-147?page=comments#action_12372157 ] 
            
Koen Aers commented on GPD-147:
-------------------------------

There are still a lot of issues with the synchronization of the xml page and the graphical page. They will not be fixed for the upcoming GA, but surely need to be fixed over time after this release.
Everybody is welcome to add any other problems one might have with this.

Thanks,
Koen

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 17:48:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Tue, 14 Aug 2007 17:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24591131.1187128081232.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372158 ] 
            
John Ruud commented on GPD-77:
------------------------------

Koen,

XmlAdapter.initialize(SemanticElement) is invoked when loading the PD diagram, but not when adding objects from the palette (which is when I need to initialize my semantic elements), so I don't believe this approach would work.

I'm not very familiar with the design behind GD, but my first thought was that it was the semantic elements (the "model objects"?) themselves that should get initialized, and that the xml adapters etc. would just get updated to reflect this (obviously this is not the case when reading the xml, when the xml adapters are used to re-create the semantic elements). Because of this it seems to me like the GD should provide some way of creating initialized semantic elements, for example by invoking some SemanticElement.initializeNew() - like method. This code would get invoked when adding objects from the palette (I think that may be the only case), but not for example while loading the diagram from xml (however, I'm leaving the design up to you - I just need one way to do this).

Thanks, John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Tue Aug 14 17:58:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 17:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28628049.1187128681146.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Koen Aers closed GPD-147.
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

Thanks to your accurate description, I have done the change you suggest. Let me know if it helps and feel free to reopen this bug or file another if necessary.

Thanks again,
Koen

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 18:05:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 18:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3326461.1187129101526.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372164 ] 
            
Koen Aers commented on GPD-77:
------------------------------

John,

What is wrong with doing this in the constructor of the SemanticElement?

Regards,
Koen

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Tue Aug 14 18:13:01 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 14 Aug 2007 18:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12935856.1187129581435.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-147?page=comments#action_12372167 ] 
            
Imran Naqvi commented on GPD-147:
---------------------------------

sweet! thanx a lot...I'll test it out.

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 18:23:05 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 18:23:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1902751.1187130185055.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372168 ] 
            
Koen Aers commented on GPD-77:
------------------------------

So I answered to quickly (it is already past midnight here ;-) )

The solution for your problem is using either the initialize() method or do the initialization in the constructor. If the constructor or the initialize() method gets called when reading the diagram from the xml, you *have* to make sure in the adapter that the proper values for the attributes and nested elements are written into the newly created (and possibly wrongly initialized) semantic element object. This is done by the XmlAdapter.initialze(SemanticElement) method for the XmlAdapter of this particular semantic element.

Have e.g. a look at the Task/TaskDomAdapter combo. Newly created instances of a task have attributes initialized to particular values. The initalize(SemanticElement) method in TaskDomAdapter will override these attributes with the values found in the xml.

Hope this helps,
Koen

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Tue Aug 14 18:23:05 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 14 Aug 2007 18:23:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15315910.1187130185215.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-147?page=comments#action_12372169 ] 
            
Imran Naqvi commented on GPD-147:
---------------------------------

seems to work fine. Thanks.

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 19:00:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-301) Use Hermes in
 top of Messaging
Message-ID: <22313526.1187132401294.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-301:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> Use Hermes in top of Messaging
> ------------------------------
>
>                 Key: JBMESSAGING-301
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-301
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: Unscheduled
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:02:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-737) Automate
 MemoryLeak tests on cruisecontrol
In-Reply-To: <6979308.1168451427306.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9694353.1187132521246.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-737:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> Automate MemoryLeak tests on cruisecontrol
> ------------------------------------------
>
>                 Key: JBMESSAGING-737
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-737
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: Unscheduled
>
>
> MemoryLeak tests are dependent on JBossProfiler library. I need to verify binary dependencies on cruisecontrol 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 lists.jboss.org  Tue Aug 14 19:02:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-574) In memory
 replication of persistent messages
In-Reply-To: <32027069.1159809401687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10511966.1187132521724.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-574:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> In memory replication of persistent messages
> --------------------------------------------
>
>                 Key: JBMESSAGING-574
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-574
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: Unscheduled
>
>
> We should enable an option whereby persisted messages can be replicated between nodes rather than persisted to disk

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:02:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1016) Find some way
 of speeding up the test suite
In-Reply-To: <16171804.1184778047440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30368661.1187132521852.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1016.
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)
       Resolution: Duplicate Issue

> Find some way of speeding up the test suite
> -------------------------------------------
>
>                 Key: JBMESSAGING-1016
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1016
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: Unscheduled
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:04:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1021) Move client
 side transaction state to the server side
In-Reply-To: <1163351.1185399527336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29795917.1187132641257.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

A negative point to this is that maintaining transactional state on the server side makes failover more difficult since that state needs to be synchronously replicated to the buddy.

> Move client side transaction state to the server side
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1021
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1021
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> Currently we hold the incomplete JMS transactional state on the client side and send it all in one go on commit.
> Instead we should store it on the server side. This will simplify things and allow larger transactions to be built without a large pause on commit or exhausting client side memory

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:04:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-380) Use JBoss retro
Message-ID: <31415193.1187132641627.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-380.
-------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)
       Resolution: Rejected

We are now Java 5 only

> Use JBoss retro
> ---------------
>
>                 Key: JBMESSAGING-380
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-380
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: Unscheduled
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We should consider using JBossRetro in JBossMessaging. This will allow us to use JDK1.5 specific features in the code base, but will still run on JDK1.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 lists.jboss.org  Tue Aug 14 19:04:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-697) Convert crash
 tests to use new server management framework
In-Reply-To: <4077302.1166743838482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20522809.1187132641968.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-697.
-------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: 2.0.0 Beta 1)
       Resolution: Done

> Convert crash tests to use new server management framework
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-697
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-697
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.4.0.CR2
>
>
> Now the testing framework supports the ability to kill and restart servers we should transfer the crash tests across to this new way of doing 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 lists.jboss.org  Tue Aug 14 19:06:13 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-750) Remove manually
 spawning of servers from runtest and build.xml
In-Reply-To: <29080858.1169026612896.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20668044.1187132773563.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-750.
-------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: 2.0.0 Beta 1)
       Resolution: Done
         Assignee: Tim Fox

> Remove manually spawning of servers from runtest and build.xml
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-750
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-750
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.4.0.CR2
>
>
> Both runtest and tests/build.xml still use startrmiserver to start (and stop) remote servers prior (and after) to test run.
> The test framework now has the ability to start servers programmatically so this should be unnecessary. Removing it wil aid clarity of test scripts

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:06:13 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-222) Run "findbugs"
 on the code base
Message-ID: <20542732.1187132773751.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-222:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> Run "findbugs" on the code base
> -------------------------------
>
>                 Key: JBMESSAGING-222
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-222
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: Unscheduled
>
>         Attachments: build.xml, findbugs-0.9.5.zip, findbugs.patch, findbugs.patch, report-fb.xml
>
>
> Run "findbugs" or similar regularily on the code base. Integrate it in the continous build 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 lists.jboss.org  Tue Aug 14 19:10:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases, also DB2
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12725703.1187133001100.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

DB2 will take a bit extra work. So putting the DB2 work in a different task

> Ensure successfull test run against all supported databases, also DB2
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:10:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1048) Test DB2
 config against Hudson
Message-ID: <16680822.1187133001211.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test DB2 config against Hudson
------------------------------

                 Key: JBMESSAGING-1048
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1048
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 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 lists.jboss.org  Tue Aug 14 19:15:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-742) Update of
 JBossRemoting to Alpha4 and JBMESSAGING-741
In-Reply-To: <15501215.1168535007057.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29297509.1187133301191.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox reopened JBMESSAGING-742:
---------------------------------

             

> Update of JBossRemoting to Alpha4 and JBMESSAGING-741
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-742
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-742
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>    Affects Versions: 1.0.1.SP2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.2.CR1, 1.0.1.SP2
>
>         Attachments: jboss-messaging-client.jar, jboss-messaging.jar, jboss-remoting.jar
>
>
> PATCH NAME: 
>         JBMESSAGING-742
> PRODUCT NAME:
>         JBoss Messaging
> VERSION:
>         1.0.1.SP2        
> SHORT DESCRIPTION: 
>         This Patch will fix the reference to JMSDestination from Messages after a queue is restarted or redeployed, as well fixes introduced by Remoting Alpha4
> LONG DESCRIPTION: 
>         Prior to this fix, when a queue was restarted, you would get a null reference on message.getJMSDestination when receiving a message.
> MANUAL INSTALL INSTRUCTIONS:
>         Replace jboss-messaging.jar and jboss-remoting.jar under jboss-messaging.sar
>         Also replace eventual usages of jboss-messaging-client.jar.
> COMPATIBILITY: 
>         This patch is compatible with 1.0.1.SP2. No issues were introduced by this patch.
> CREATOR:
>         Clebert Suconic
> DATE:
>         Jan, 11th 2007

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:15:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-742) Update of
 JBossRemoting to Alpha4 and JBMESSAGING-741
In-Reply-To: <15501215.1168535007057.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7938341.1187133301365.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox resolved JBMESSAGING-742.
---------------------------------

    Resolution: Done

> Update of JBossRemoting to Alpha4 and JBMESSAGING-741
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-742
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-742
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>    Affects Versions: 1.0.1.SP2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.SP2, 1.0.2.CR1
>
>         Attachments: jboss-messaging-client.jar, jboss-messaging.jar, jboss-remoting.jar
>
>
> PATCH NAME: 
>         JBMESSAGING-742
> PRODUCT NAME:
>         JBoss Messaging
> VERSION:
>         1.0.1.SP2        
> SHORT DESCRIPTION: 
>         This Patch will fix the reference to JMSDestination from Messages after a queue is restarted or redeployed, as well fixes introduced by Remoting Alpha4
> LONG DESCRIPTION: 
>         Prior to this fix, when a queue was restarted, you would get a null reference on message.getJMSDestination when receiving a message.
> MANUAL INSTALL INSTRUCTIONS:
>         Replace jboss-messaging.jar and jboss-remoting.jar under jboss-messaging.sar
>         Also replace eventual usages of jboss-messaging-client.jar.
> COMPATIBILITY: 
>         This patch is compatible with 1.0.1.SP2. No issues were introduced by this patch.
> CREATOR:
>         Clebert Suconic
> DATE:
>         Jan, 11th 2007

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:17:14 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:17:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-26) Standalone
 Messaging configuration.
Message-ID: <3937073.1187133434263.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-26:
-------------------------------

    Assignee:     (was: Alex Pinkin)

> Standalone Messaging configuration.
> -----------------------------------
>
>                 Key: JBMESSAGING-26
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-26
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>            Reporter: Ovidiu Feodorov
>             Fix For: 2.0.0 Beta 1
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> Prepare a stripped-down JBoss configuration that will be the "stand-alone" JBoss Messaging server. 
> Must have at least the JNDI server, Logging, Remoting and AOP support.
> We should provide a pre-packaged downloadable "standalone" config - users don't want to have to download and install the AS just so they can create a standalone installation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:17:14 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:17:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-693) Starting two
 node clusters
 simultaneously may end in failed messaging server node boot
In-Reply-To: <4904424.1166611478826.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11829548.1187133434550.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-693.
-------------------------------

    Resolution: Done

> Starting two node clusters simultaneously may end in failed messaging server node boot
> --------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-693
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-693
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.CR1
>
>
> Tim Fox: 10:24:05,296 ERROR [DefaultClusteredPostOffice] Caught Exception in RequestHandler
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.addBindingFromCluster(DefaultClusteredPostOffice.java:597)
>         at org.jboss.messaging.core.plugin.postoffice.cluster.BindRequest.execute(BindRequest.java:55)
>         at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$PostOfficeRequestHandler.handle(DefaultClusteredPostOffice.java:2526)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:602)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:623)
>         at org.jgroups.blocks.RequestCorrelator.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 lists.jboss.org  Tue Aug 14 19:19:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-858)
 org.jboss.test.messaging.jms.bridge.ReconnectTest times out while run over
 HTTP
In-Reply-To: <21901867.1171955138087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17559075.1187133541210.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-858.
-------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: Unscheduled)
       Resolution: Done
         Assignee: Tim Fox

> org.jboss.test.messaging.jms.bridge.ReconnectTest times out while run over HTTP
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-858
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-858
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> ReconnectTests actually pass for both bisocket and HTTP, but the cleanup fails for HTTP, causing the test to hang and timeout. 
> All individual tests have been modified to exit for HTTP. They need to be re-enabled, and the HTTP cleanup issue fixed.
> Search for JBMESSAGING-858 in the code and re-enable the 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 lists.jboss.org  Tue Aug 14 19:24:01 2007
From: jira-events at lists.jboss.org (Steven Holmes (JIRA))
Date: Tue, 14 Aug 2007 19:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6216566.1187133841814.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12372175 ] 
            
Steven Holmes commented on JBPORTAL-1626:
-----------------------------------------

Here is running on a Sun Solaris 10 server:

16:13:21,404 ERROR [ContentGetCommand] Cannot get content
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/wsp_node/acff7658-2ca1-4473-ae27-b96a3f0a634a, ca
ller=Thread[http-192.168.0.235-9080-1,5,jboss], lock=write owner=GlobalTransaction:<null>:5 (activeReaders=0, activeWriter=Thread[http-192.168.0.
235-9080-1,5,jboss], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
        at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.exists(JBossCachePersistenceManager.java:508)
        at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:906)
        at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:271)
        at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:179)
        at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:261)
        at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
        at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:461)
        at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:319)
        at org.apache.jackrabbit.core.PropertyImpl.getNode(PropertyImpl.java:656)
        at org.apache.jackrabbit.core.NodeImpl.getVersionHistory(NodeImpl.java:3148)
        at org.jboss.portal.cms.impl.jcr.command.ContentGetCommand.execute(ContentGetCommand.java:109)
        at org.jboss.portal.cms.impl.jcr.JCRCommandContext.execute(JCRCommandContext.java:75)
        at org.jboss.portal.cms.impl.jcr.command.FileGetCommand.execute(FileGetCommand.java:113)
        at org.jboss.portal.cms.impl.jcr.JCRCMS$1.invoke(JCRCMS.java:118)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.cms.impl.interceptors.ApprovalWorkflowInterceptor.invoke(ApprovalWorkflowInterceptor.java:116)
        at org.jboss.portal.cms.CMSInterceptor.invoke(CMSInterceptor.java:36)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.cms.impl.interceptors.ACLInterceptor.invoke(ACLInterceptor.java:248)
        at org.jboss.portal.cms.CMSInterceptor.invoke(CMSInterceptor.java:36)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.cms.impl.jcr.JCRCMS.execute(JCRCMS.java:630)
        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 $Proxy229.execute(Unknown Source)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:221)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSup
ported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java
:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke
$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:1
16)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke
$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericContentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(Tra
nsactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/wsp_node/acff7658-2ca1-4473-ae27-b96a3f0a634a, caller=Thread[http-
192.168.0.235-9080-1,5,jboss], lock=write owner=GlobalTransaction:<null>:5 (activeReaders=0, activeWriter=Thread[http-192.168.0.235-9080-1,5,jbos
s], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
        at org.jboss.cache.Node.acquire(Node.java:500)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:379)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:307)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:181)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:212)
        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.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:186)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:365)
        at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
        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:5863)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3627)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3608)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3595)
        at sun.reflect.GeneratedMethodAccessor320.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 $Proxy199.get(Unknown Source)
        at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.exists(JBossCachePersistenceManager.java:469)
        ... 270 more
Caused by: org.jboss.cache.lock.TimeoutException: read lock for /wsp_node/acff7658-2ca1-4473-ae27-b96a3f0a634a could not be acquired by Thread[ht
tp-192.168.0.235-9080-1,5,jboss] after 15000 ms. Locks: Read lock owners: []
Write lock owner: GlobalTransaction:<null>:5
, lock info: write owner=GlobalTransaction:<null>:5 (activeReaders=0, activeWriter=Thread[http-192.168.0.235-9080-1,5,jboss], waitingReaders=0, w
aitingWriters=0, waitingUpgrader=0)
        at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:262)
        at org.jboss.cache.Node.acquireReadLock(Node.java:512)
        at org.jboss.cache.Node.acquire(Node.java:474)
        ... 299 more
16:13:21,538 ERROR [org_jboss_portal_core_cms_ui_CMSPortlet] The portlet threw an exception
java.lang.NullPointerException
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:235)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSup
ported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java
:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke
$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:1
16)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke
$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericContentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(Tra
nsactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)
16:13:21,564 ERROR [DefaultPageControlPolicy] Rendering portlet window  produced an error
java.lang.NullPointerException
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:235)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSup
ported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java
:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke
$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:1
16)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke
$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericContentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(Tra
nsactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 20:06:01 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 14 Aug 2007 20:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1630) WindowState and
 Mode comparator severely broken
Message-ID: <22181787.1187136361049.JavaMail.jira@cloud.prod.atl2.jboss.com>

WindowState and Mode comparator severely broken
-----------------------------------------------

                 Key: JBPORTAL-1630
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1630
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 Final


- not thread safe
- is using family for comparison instead of 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 lists.jboss.org  Tue Aug 14 20:16:01 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 14 Aug 2007 20:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1623) Create "Admin"
 icon for the different themes for the new admin portlet mode
In-Reply-To: <19138744.1186510029362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15462499.1187136961203.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1623?page=comments#action_12372177 ] 
            
Julien Viet commented on JBPORTAL-1623:
---------------------------------------

Done for renaissance theme

> Create "Admin" icon for the different themes for the new admin portlet mode
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1623
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1623
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.6.3 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 lists.jboss.org  Tue Aug 14 20:16:01 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 14 Aug 2007 20:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1630) WindowState and
 Mode comparator severely broken
In-Reply-To: <22181787.1187136361049.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29106641.1187136961322.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Julien Viet resolved JBPORTAL-1630.
-----------------------------------

    Resolution: Done

> WindowState and Mode comparator severely broken
> -----------------------------------------------
>
>                 Key: JBPORTAL-1630
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1630
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> - not thread safe
> - is using family for comparison instead of 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 lists.jboss.org  Tue Aug 14 20:45:12 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 20:45:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1084) Provide case
 insentive
 completions in eth DRL Editor for MVEL and Java completions
Message-ID: <24431326.1187138712419.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide case insentive completions in eth DRL Editor for MVEL and Java completions 
-----------------------------------------------------------------------------------

                 Key: JBRULES-1084
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1084
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Philippe Ombredanne
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: 4.0.1


You do not get the same completions when typing a lower case or upper case prefix.
Completaions should be offered for all the lower or uppercase prefix

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 20:49:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 20:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1084) Provide case
 insentive
 completions in eth DRL Editor for MVEL and Java completions
In-Reply-To: <24431326.1187138712419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3684230.1187138941129.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne resolved JBRULES-1084.
------------------------------------------

    Resolution: Done

Fixed.
This was a bug reported by fmeyer

> Provide case insentive completions in eth DRL Editor for MVEL and Java completions 
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-1084
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1084
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Philippe Ombredanne
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> You do not get the same completions when typing a lower case or upper case prefix.
> Completaions should be offered for all the lower or uppercase prefix

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 20:58:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 20:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1080) Modify (var)
 added to Eclipse code completion for mvel
In-Reply-To: <19252810.1187049901307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13129382.1187139481131.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne resolved JBRULES-1080.
------------------------------------------

    Resolution: Done
      Assignee: Mark Proctor  (was: Philippe Ombredanne)

Fixed. Not applying macro processing to massaged mvel xpre4ssion was the issue

> Modify (var) added to Eclipse code completion for mvel
> ------------------------------------------------------
>
>                 Key: JBRULES-1080
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1080
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Mark Proctor
>            Priority: Minor
>         Attachments: mvel.png
>
>
> Reported by Mark: 
> I've found a weird one with context assist, some how its adding "modify ( var )" to the list of context completions, but it only does that if you've already added the line to the consequence. See modify( game ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 21:00:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 21:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1084) Provide case
 insentive
 completions in eth DRL Editor for MVEL and Java completions
In-Reply-To: <24431326.1187138712419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24623275.1187139601177.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne reassigned JBRULES-1084:
--------------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

for your review

> Provide case insentive completions in eth DRL Editor for MVEL and Java completions 
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-1084
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1084
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Philippe Ombredanne
>         Assigned To: Fernando Meyer
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> You do not get the same completions when typing a lower case or upper case prefix.
> Completaions should be offered for all the lower or uppercase prefix

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 02:19:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 15 Aug 2007 02:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14638977.1187158741186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen resolved JBAOP-449.
----------------------------------

    Resolution: Done

fixed bug in svn

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Wed Aug 15 02:35:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 15 Aug 2007 02:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24479531.1187159701742.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Stale Pedersen resolved JBAOP-453.
----------------------------------

    Resolution: Done

with input/help from paul gier i've changed how we build the classpath, from using project.artifacts, to plugin.artifacts.
the dependencies within the pom will stay as they are atm. this will make it as easy as possible for the end user to aopc with maven.
the plan is that each new release of aop, will have a similar maven-plugin release. - and they will have the same version to prevent confusion.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug 15 02:35:02 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 15 Aug 2007 02:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14812457.1187159702026.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372199 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

- we will document this on the wiki and the bundled documentation when we release 2.0

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug 15 04:16:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Wed, 15 Aug 2007 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10910584.1187165761466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372213 ] 
            
John Ruud commented on GPD-77:
------------------------------

Thanks Koen, *now* I understand (and it seems to work!)

John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Wed Aug 15 04:34:01 2007
From: jira-events at lists.jboss.org (stefan lotties (JIRA))
Date: Wed, 15 Aug 2007 04:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4609) Original
 SevletResponse or
 wrapped original ServletResponse not passed to RequestDispatcher in
 violation of SRV.8.2 and SRV.14.2.5.1
Message-ID: <14152110.1187166841533.JavaMail.jira@cloud.prod.atl2.jboss.com>

Original SevletResponse or wrapped original ServletResponse not passed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4609
                 URL: http://jira.jboss.com/jira/browse/JBAS-4609
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.0.GA
         Environment: RHeL
            Reporter: stefan lotties


Sometimes in the log the following stacktrace appears while someone is surfing in an application:
2007-08-09 12:10:01,834 [http-0.0.0.0-8080-1] ERROR org.apache.catalina.core.ContainerBase.[jboss.we
b].[localhost].[/webadmin].[action] - Servlet.service() for servlet action threw exception
javax.servlet.ServletException: Original SevletResponse or wrapped original ServletResponse not pass
ed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
        at org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.jav
a:1018)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:329)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
        at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056)
        at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261)
        at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcesso
r.java:237)
        at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.
java:300)
        at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231)
        at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
        at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
        at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:271)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:
469)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
        at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.
java:316)
        at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:2
44)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:
156)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
va:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595) 

I debugged as far as I could and noticed that the http-request returns the host the jboss runs on when calling HttpServletRequest.getRemoteHost() and has "HEAD" as method. It can't be reproduced since it seems to be kinda random (doing the same action twice or more often does not end in this exception). Also the requested-URIs are different. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 04:34:02 2007
From: jira-events at lists.jboss.org (stefan lotties (JIRA))
Date: Wed, 15 Aug 2007 04:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4609) Original
 SevletResponse or
 wrapped original ServletResponse not passed to RequestDispatcher in
 violation of SRV.8.2 and SRV.14.2.5.1
In-Reply-To: <14152110.1187166841533.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29630881.1187166842066.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4609?page=comments#action_12372220 ] 
            
stefan lotties commented on JBAS-4609:
--------------------------------------

btw: This "problem" does not affect anything. It's just irritating for our customers. Also this never appeared with jboss 4.0.5 GA.

> Original SevletResponse or wrapped original ServletResponse not passed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4609
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4609
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: RHeL
>            Reporter: stefan lotties
>
> Sometimes in the log the following stacktrace appears while someone is surfing in an application:
> 2007-08-09 12:10:01,834 [http-0.0.0.0-8080-1] ERROR org.apache.catalina.core.ContainerBase.[jboss.we
> b].[localhost].[/webadmin].[action] - Servlet.service() for servlet action threw exception
> javax.servlet.ServletException: Original SevletResponse or wrapped original ServletResponse not pass
> ed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
>         at org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.jav
> a:1018)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:329)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056)
>         at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261)
>         at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcesso
> r.java:237)
>         at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.
> java:300)
>         at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231)
>         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
>         at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
>         at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:271)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
> ava:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
>         at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:
> 469)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.
> java:316)
>         at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:2
> 44)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:
> 156)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
> va:580)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595) 
> I debugged as far as I could and noticed that the http-request returns the host the jboss runs on when calling HttpServletRequest.getRemoteHost() and has "HEAD" as method. It can't be reproduced since it seems to be kinda random (doing the same action twice or more often does not end in this exception). Also the requested-URIs are different. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 06:01:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 15 Aug 2007 06:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-81) Add support for
 reconnecting transitions
In-Reply-To: <898355.1178879092359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31705722.1187172061237.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-81?page=comments#action_12372232 ] 
            
Ronald van Kuijk commented on GPD-81:
-------------------------------------

YEAAAAAAHHHHHHHH WAY TO GO.....

I have to admit... the designer is getting better by the month/week... I regulary check everything out, build it and try it....... 

> Add support for reconnecting transitions
> ----------------------------------------
>
>                 Key: GPD-81
>                 URL: http://jira.jboss.com/jira/browse/GPD-81
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: Clean eclipse 3.2.2 and gpd 3.1alpha4
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> Not being able to reconnect transitions graphically from e.g. node a to node b is still a big omission for the gpd to be used by 'grey suites' as well as 'jeans and t-shirts', at least within our company. I thought there was a long standing issue for this, but I cannot find it. 
> If someone could point me to a place to start looking into this, I'd be happy to try to implement this (but it will be the only gpd thing I 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 lists.jboss.org  Wed Aug 15 06:01:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 06:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4600) Rename JBossMQ
 variables from jboss-messaging to jboss.messaging-mq.lib
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21413685.1187172061352.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4600:
-------------------------------------

    Summary: Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib  (was: Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty)

> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib
> -----------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 06:58:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 06:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1143) Migrate
 repository from CVS to SVN
In-Reply-To: <5716848.1184844227121.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7249329.1187175481001.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1143?page=all ]

Manik Surtani resolved JBCACHE-1143.
------------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Migrate repository from CVS to SVN
> ----------------------------------
>
>                 Key: JBCACHE-1143
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1143
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:00:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1144) Update build
 system to use Maven2 rather than Ant
In-Reply-To: <7905246.1184844227204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17334173.1187175601052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1144?page=all ]

Manik Surtani resolved JBCACHE-1144.
------------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Update build system to use Maven2 rather than Ant
> -------------------------------------------------
>
>                 Key: JBCACHE-1144
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1144
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:00:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1147) Document changes
In-Reply-To: <11638383.1184844347023.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28306007.1187175601140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1147?page=all ]

Manik Surtani resolved JBCACHE-1147.
------------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Document changes
> ----------------
>
>                 Key: JBCACHE-1147
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1147
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:12:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-1145) Update test
 suite to use TestNG
In-Reply-To: <32594581.1184844227288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19646453.1187176321234.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1145?page=all ]

Manik Surtani reassigned JBCACHE-1145:
--------------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> Update test suite to use TestNG
> -------------------------------
>
>                 Key: JBCACHE-1145
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1145
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:12:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1146) Parameterise
 tests for various permutations
In-Reply-To: <6430365.1184844227374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18795607.1187176321349.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1146?page=all ]

Manik Surtani updated JBCACHE-1146:
-----------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> Parameterise tests for various permutations
> -------------------------------------------
>
>                 Key: JBCACHE-1146
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1146
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:14:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1145) Update test suite
 to use TestNG
In-Reply-To: <32594581.1184844227288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4797663.1187176441144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1145?page=all ]

Manik Surtani updated JBCACHE-1145:
-----------------------------------

    Fix Version/s: 2.1.0.GA

> Update test suite to use TestNG
> -------------------------------
>
>                 Key: JBCACHE-1145
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1145
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:14:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1146) Parameterise
 tests for various permutations
In-Reply-To: <6430365.1184844227374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22779565.1187176441268.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1146?page=all ]

Manik Surtani updated JBCACHE-1146:
-----------------------------------

    Fix Version/s: 2.1.0.GA

> Parameterise tests for various permutations
> -------------------------------------------
>
>                 Key: JBCACHE-1146
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1146
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:30:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 07:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-35) enhancement drawing
	transitions
In-Reply-To: <9729958.1168962532978.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9672616.1187177401067.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-35?page=comments#action_12372242 ] 
            
Koen Aers commented on GPD-35:
------------------------------

I'll certainly have a look at this, but my GEF knowledge is currently not at the point that I know directly how I should attack this. It will need some investigation, if possible at all.
If anyone knows of an example of this with GEF, please direct me to it...

Regards,
Koen

> enhancement drawing transitions
> -------------------------------
>
>                 Key: GPD-35
>                 URL: http://jira.jboss.com/jira/browse/GPD-35
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> When the mousepointer is in the outer area of a node/state/task/.... but within it's boundaries, it should be possible to draw a transition. This is makes using the gpd a lot faster (not switching in the toolbar)
> Maybe it should only be in the 'middle areas' of top, bottom, left and right and not the corners

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:41:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 07:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-139) Cannot add tasks to
	the task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15474077.1187178061148.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-139?page=comments#action_12372243 ] 
            
Koen Aers commented on GPD-139:
-------------------------------

Hm, I am afraid I could not reproduce this. Or maybe I fixed this already without knowing. Can anyone verify if the problem still exists?

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:47:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 15 Aug 2007 07:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1030) Implement EE
 8.2.1 section 2 functionality
Message-ID: <31360626.1187178421124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement EE 8.2.1 section 2 functionality
------------------------------------------

                 Key: EJBTHREE-1030
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1030
             Project: EJB 3.0
          Issue Type: Sub-task
            Reporter: Carlo de Wolf
             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug 15 07:49:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 15 Aug 2007 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1031) only 4 equality
 checks are made for fact
In-Reply-To: <9998356.1185475797431.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10095913.1187178541189.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1031:
-----------------------------------

    Summary: only 4 equality checks are made for fact  (was: using Not only allows me to use 4 equality checks for fact)

> only 4 equality checks are made for fact
> ----------------------------------------
>
>                 Key: JBRULES-1031
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1031
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Fedora 7, JDK 1.5.0_12
>            Reporter: Eric Miles
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: drools-not-fact-test.tar.gz
>
>
> I have a single rule in my test bed as such:
> rule "5th Item Not Test"
>     
>     when
>         $first : FirstClass($i1 : item1, $i2 : item2, $i3 : item3, $i4 : item4, $i5 : item5)
>         not SecondClass(item1 == $i1, item2 == $i2, item3 == $i3, item4 == $i4, item5 == $i5)
>     then
>         System.out.println("NOT test matched");
>        
> end
> In the not SecondClass() section of the test, the last equality checks always fail, no matter what it is.  I can switch the order around of the checks, no matter what the last one is, it causes THEN clause to not fire, even when I am absolutely positive there is not a match.  (I can remove the not and the equality works fine).  Is there a limit on the number of equality tests I can do with a not?  It seems as though it is 4.  I have attached a test case that can reproduce this (it is different from my project's code, but I have been able to reproduce this in multiple projects).  It is a maven Eclipse project and includes a junit with some minor instructions.  I have created a rule that will fire as the opposite of the rule I'm trying to test and it prints out the values to the console.  You can see in the console that the values are not equal, although the rule fired that they were.
> If these instructions do not make sense, please email me. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 08:25:01 2007
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Wed, 15 Aug 2007 08:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4606) Hypersonic server
 mode TCP socket problem
In-Reply-To: <5093937.1187090041430.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23419749.1187180701536.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4606?page=comments#action_12372259 ] 
            
Martin Vecera commented on JBAS-4606:
-------------------------------------

I discovered following error in server.log today.
It seems like I have to wait 5 minutes after JBossAS shutdown before the driver can work again. But no Java process is left (ps aux and jps reports nothing interesting). I'm not sure if it is the same problem as I experienced yesterday :-( No 'localhost' tricks are working except for the 5 minute break.

2007-08-15 14:45:11,245 DEBUG [org.jboss.system.ServiceController] starting service jboss.ejb:service=EJBTimerService,persistencePolicy=database
2007-08-15 14:45:11,245 DEBUG [org.jboss.ejb.txtimer.DatabasePersistencePolicy] Starting jboss.ejb:service=EJBTimerService,persistencePolicy=database
2007-08-15 14:45:11,259 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: run() entered
2007-08-15 14:45:11,259 INFO  [STDOUT] [Server at 862041]: Initiating startup sequence...
2007-08-15 14:45:11,259 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.database=/var/lib/jbossas/server/default/data/hypersonic/default
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.tls=false
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.port=1701
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.trace=true
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.database.0=/var/lib/jbossas/server/default/data/hypersonic/default
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.restart_on_shutdown=false
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.no_system_exit=true
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.silent=false
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.default_page=index.html
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.address=localhost
2007-08-15 14:45:11,261 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.dbname.0=
2007-08-15 14:45:11,261 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.root=.
2007-08-15 14:45:11,331 INFO  [STDOUT] DriverManager.getDriver("jdbc:hsqldb:hsql://localhost:1701")
2007-08-15 14:45:11,331 INFO  [STDOUT] DriverManager.initialize: jdbc.drivers = null
2007-08-15 14:45:11,331 INFO  [STDOUT] JDBC DriverManager initialized
2007-08-15 14:45:11,331 INFO  [STDOUT] getDriver: no suitable driver
2007-08-15 14:45:11,336 INFO  [STDOUT] java.sql.SQLException: No suitable driver
	at java.sql.DriverManager.getDriver(DriverManager.java:243)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.isDriverLoadedForURL(LocalManagedConnectionFactory.java:300)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getDriver(LocalManagedConnectionFactory.java:264)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:170)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
	at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
	at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
	at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
	at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
	at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
	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 org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	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 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 $Proxy42.start(Unknown Source)
	at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
	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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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.Ma
2007-08-15 14:45:11,336 INFO  [STDOUT] inDeployer.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:508)
	at java.lang.Thread.run(Thread.java:595)
SQLException: SQLState(08001)
2007-08-15 14:45:11,339 INFO  [STDOUT] registerDriver: driver[className=org.hsqldb.jdbcDriver,org.hsqldb.jdbcDriver at 11cccce]
2007-08-15 14:45:11,339 INFO  [STDOUT] DriverManager.getDriver("jdbc:hsqldb:hsql://localhost:1701")
2007-08-15 14:45:11,339 INFO  [STDOUT]     trying driver[className=org.hsqldb.jdbcDriver,org.hsqldb.jdbcDriver at 11cccce]
2007-08-15 14:45:11,339 INFO  [STDOUT] getDriver returning driver[className=org.hsqldb.jdbcDriver,org.hsqldb.jdbcDriver at 11cccce]
2007-08-15 14:45:11,388 INFO  [STDOUT] SQLException: SQLState(IM001) vendor code(-20)
2007-08-15 14:45:11,392 INFO  [STDOUT] java.sql.SQLException: This function is not supported
	at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
	at org.hsqldb.jdbc.Util.<clinit>(Unknown Source)
	at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
	at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
	at org.hsqldb.jdbcDriver.connect(Unknown Source)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
	at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
	at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
	at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
	at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
	at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
	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 org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	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 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 $Proxy42.start(Unknown Source)
	at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
	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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:1
2007-08-15 14:45:11,392 INFO  [STDOUT] 025)
	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:508)
	at java.lang.Thread.run(Thread.java:595)
SQLException: SQLState(08000) vendor code(-80)
2007-08-15 14:45:11,401 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.parentTraceEnabled=true
2007-08-15 14:45:11,401 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.nestedTraceEnabled=false
2007-08-15 14:45:11,401 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true
2007-08-15 14:45:11,398 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)


> Hypersonic server mode TCP socket problem
> -----------------------------------------
>
>                 Key: JBAS-4606
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4606
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: Sun JVM, x86_64&i686, RHEL5, JBossAS conf. "default", running as service jbossas.
>            Reporter: Martin Vecera
>         Assigned To: Dimitris Andreadis
>
> I wanted to deploy Duke's bank J2EE example. This requires HSQLDB in server mode. The server/deploy/hsqldb-ds.xml is well prepared for switching HSQLDB to server mode, so I did it. This XML file uses ${jboss.bind.address} property to determine HSQLDB binding address.
> I was running JBossAS with 'service jbossas start'. In /etc/sysconfig/jbossas I had JBOSS_IP=127.0.0.1.
> I got the following error:
> 2007-08-14 13:27:30,715 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
> org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:179)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
>         at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
>         at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
>         at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
>         at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
>         at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
>         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 org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         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 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 $Proxy42.start(Unknown Source)
>         at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
>         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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:508)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.sql.SQLException: socket creation error
>         at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
>         at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
>         at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
>         at org.hsqldb.jdbcDriver.connect(Unknown Source)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
>         ... 122 more
> When I replaced the {$jboss.bind.address} (both occurences in hsqldb-ds.xml) with 'localhost' everything was OK.
> So I tried to replace it with 127.0.0.1 and got the same error.
> Then I tried to put the ${jboss.bind.address} property back and changed JBOSS_IP in /etc/sysconfig/jbossas to 'localhost'.
> Well, everything was working then.
> So I returned JBOSS_IP=127.0.0.1 back and voila - everything is OK!!!
> I tried it twice on two different machines. Once I used JBOSS_IP=localhost I was able to use any of the previously mentioned configuration and it was working. VERY STRANGE! After each change I restarted JBossAS completely.
> I tried nslookup at the beginning to see if it is bound corectly:
> [root at xen61 deploy]# nslookup 127.0.0.1
> Server:         10.34.32.125
> Address:        10.34.32.125#53
> 1.0.0.127.in-addr.arpa  name = localhost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 08:36:01 2007
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 15 Aug 2007 08:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-995) CLONE -concurrent job
 acquirement fails
In-Reply-To: <29948611.1182451552483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3454275.1187181361596.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-995?page=all ]

Tom Baeyens closed JBPM-995.
----------------------------

    Fix Version/s: jBPM jPDL 3.2.2
       Resolution: Done

The static synchronization was added on the JobExecutor object.

Furthermore, the logging of optimistic locking failures is made configurable.  This is what was added to the user guide:

6.4. Logging of optimistic concurrency exceptions
When running in a cluster, jBPM synchronizes on the database. By default with optimistic locking. This means that each operation is performed in a transaction. And if at the end a collision is detected, then the transaction is rolled back and has to be handled. E.g. by a retry. So optimistic locking exceptions are usually part of the normal operation. Therefor, by default, the org.hibernate.StateObjectStateExceptions the that hibernate throws in that case are not logged with error and a stack trace, but instead a simple info message 'optimistic locking failed' is displayed. 

Hibernate itself will log the StateObjectStateException including a stack trace. If you want to get rid of these stack traces, put the level of org.hibernate.event.def.AbstractFlushingEventListener to FATAL. If you use log4j following line of configuration can be used for that: 

log4j.logger.org.hibernate.event.def.AbstractFlushingEventListener=FATAL

If you want to enable logging of the jBPM stack traces, add the following line to your jbpm.cfg.xml: 

<boolean name="jbpm.hide.stale.object.exceptions" value="false" />


> CLONE -concurrent job acquirement fails
> ---------------------------------------
>
>                 Key: JBPM-995
>                 URL: http://jira.jboss.com/jira/browse/JBPM-995
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>            Reporter: Edward Staub
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>
> when more than 1 job executor thread is configured and concurrent async nodes are to be executed, it results in hibernate exceptions.
> reason: job acquirement is not synchronized well, resulting in multiple threads trying to work on the same job.
> In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been closed.  So I cloned it here..  let me know if that was incorrect process.  
> The problem was easy to reproduce, and was easy to predict in the first place.  Alex's fix (sychronize on a static class member around acquireJobs()) works for me as well.  It probably trivially improves performance, by avoiding aborted acquire attempts.
> As noted in JBPM-974, it only causes an erroneous error message being emitted - the code operates correctly.  It also makes debugging other race conditions much more difficult by injecting a lot of noise - they usually show up as stale objects as well.
> I believe the reason the trace is dumped to the log is because it's dumped at ERROR level before it even gets to JBPM, in org.hibernate.event.def.AbstractFlushingEventListener.performExecutions.  So the "catch (StaleStateException e)" doesn't suppress it - the horse has left the barn, the train has left the station, the s--t has already hit the fan - pick your favorite metaphor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 08:47:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 08:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1628) Portal bridge
	upgrade
In-Reply-To: <17053523.1187016541409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12758206.1187182021831.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1628.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

> Portal bridge upgrade
> ---------------------
>
>                 Key: JBPORTAL-1628
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1628
>             Project: JBoss Portal
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 SP1
>            Reporter: Rakesh Ajmera
>         Assigned To: Thomas Heute
>             Fix For: 2.4.2 Final, 2.6.2 Final, 2.8 Final
>
>
> There is a new version of portal-bridge available 1.0.3(http://portals.apache.org/bridges/download.html). What's the plan of upgrading jboss portal to the latest version of portal bridge?
> We need the bug fixes available in this 1.0.3 release, but it doesn't work with the jboss's portal-bridge-lib.jar that is packaged with jboss portal.   We are using Struts bridge, that is dependent on the portals-bridges-common.jar, which in turn works with JBoss's potal-bridge-lib.jar. I upgraded the portal-bridges-common.jar with the latest version, but it didn't work with portal-bridge-lib.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 lists.jboss.org  Wed Aug 15 09:17:01 2007
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Wed, 15 Aug 2007 09:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-394)
 jboss/jboss-deployers/2.0.0.Beta
Message-ID: <837463.1187183821693.JavaMail.jira@cloud.prod.atl2.jboss.com>

jboss/jboss-deployers/2.0.0.Beta
--------------------------------

                 Key: JBBUILD-394
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-394
             Project: JBoss Build System
          Issue Type: Bug
          Components: Maven
            Reporter: Pete Muir
         Assigned To: Paul Gier
            Priority: Minor


jboss-deployers-2.0.0.Beta missing jar (pom is present).



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:27:14 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:27:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1498) Add Support for
 Internet Explorer's Conditional Comments
In-Reply-To: <21678833.1182478672108.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5230807.1187184434820.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1498.
------------------------------------

    Fix Version/s:     (was: 2.8 Final)
                       (was: 2.6.2 Final)
       Resolution: Won't Fix
         Assignee: Thomas Heute  (was: Julien Viet)

So actually it should be something more generic that allows to define a different stylesheet for different User-Agents.

I close this case as "Won't fix" and open a new one with the more generic idea.

> Add Support for Internet Explorer's Conditional Comments
> --------------------------------------------------------
>
>                 Key: JBPORTAL-1498
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1498
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: All
>            Reporter: Andy Pemberton
>         Assigned To: Thomas Heute
>
> Currently, JBoss Portal's theme and layout architecture relies on XML deployment descriptors for several objects.  For example, the portal-theme.xml is used to create themes (javascript and css) that will be applied to layouts.
> The request I have is this: given the XML deployment descriptors, add in support for Internet Explorer's Conditional Comment system. 
> Conditional Comments have been a feature of IE since IE5. Basically, Conditional Comments are specially formatted HTML comments that allow web developers to target specific markup to Internet Explorer. Typically, Conditional Comments are used to import specific Cascading Style Sheets (CSS) to HTML pages to handle IE-specific CSS defects. 
> Currently, the lack of support for Conditional Comments is caused by the fact that Conditional Comments rely on XHTML-based comments, which are thus filtered out at the portal-theme.xml level. I considered adding this request as a defect, but decided against it as not reading in comments in an XML deployment descriptor is quite logical, and of course - IE's conditional comment system (though useful) is counter-intuitive. 
> Reference:
>  - http://msdn2.microsoft.com/en-us/library/ms537512.aspx

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:31:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1631) Allow different
 stylesheets for different user-agents
Message-ID: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow different stylesheets for different user-agents
-----------------------------------------------------

                 Key: JBPORTAL-1631
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Theme
            Reporter: Thomas Heute
         Assigned To: Julien Viet
             Fix For: 2.8 Final


It should be possible to define several stylesheets for a theme that would be applied for different user-agents.

Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:37:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1300) Default a
 portlet window to maximized.
In-Reply-To: <24092633.1173097870945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12374215.1187185021912.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1300:
-----------------------------------

    Fix Version/s: 2.8 Final

> Default a portlet window to maximized.
> --------------------------------------
>
>                 Key: JBPORTAL-1300
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1300
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: David Roberts
>            Priority: Optional
>             Fix For: 2.8 Final
>
>
> When adding portlets, it would be nice if there were an option where the portlet window could start out MAXIMIZED, so the entire portlet fills the screen nicely without the users having to click the maximize button. Eg. this would be very helpful when using the IFrame Portlet, so the URL being referenced fits the entire screen, and doesn't mess up the original layout of the referenced page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:44:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-206) Check that
 required fields are filled before logging in a user
Message-ID: <15991797.1187185441605.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-206:
----------------------------------

    Fix Version/s: 2.8 Final

> Check that required fields are filled before logging in a user
> --------------------------------------------------------------
>
>                 Key: JBPORTAL-206
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-206
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0.1 Final
>            Reporter: Thomas Heute
>             Fix For: 2.8 Final
>
>
> Making sure to check that a user filled all required fields before letting him logging-in. Otherwise it should display a form with non-filled entries.
> This is useful when we add a new field in the registration form.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:46:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-1148) SEAM / JSF /
 Portlet: Compatibility problem
In-Reply-To: <33157558.1164905095910.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12800845.1187185561512.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute closed JBPORTAL-1148.
----------------------------------

    Resolution: Won't Fix
      Assignee: Thomas Heute  (was: Julien Viet)

>From the JBSEAM-347 that it was a non-issue

> SEAM / JSF / Portlet: Compatibility problem
> -------------------------------------------
>
>                 Key: JBPORTAL-1148
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1148
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6.CR1
>         Environment: Windows XP
> MyFaces 1.1.5
> SEAM 1.0.1
>            Reporter: JP Barbe
>         Assigned To: Thomas Heute
>
> When I use a seam tag into a jsf page, I have the following exception (You can see config files after the exception):
> 2006-11-30 17:20:57,934 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/seam-desk]] No active conversation context
> 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.Component.getInstance(Component.java:1230)
> 	at org.jboss.seam.contexts.Lifecycle.resumeConversation(Lifecycle.java:328)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.restoreAnyConversationContext(AbstractSeamPhaseListener.java:42)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.beforePhase(SeamPortletPhaseListener.java:51)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.beforePhase(SeamExtendedManagedPersistencePortletPhaseListener.java:37)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.informPhaseListenersBefore(LifecycleImpl.java:520)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:342)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:396)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
> 	at com.eads.desk.core.portlet.DeskAccessPortlet.doView(DeskAccessPortlet.java:30)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
> #### Here is the faces-config.xml file:
> <faces-config>
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> 	
> 	
> 	<navigation-rule>
> 		<from-view-id>/view/deskAccess.jsp</from-view-id>
> 		<navigation-case>
> 			<from-outcome>trManager</from-outcome>
> 			<to-view-id>/view/viewTRManager.jsp</to-view-id>
> 			<redirect />
> 		</navigation-case>	
> 	</navigation-rule>
>     
>     <navigation-rule>
>     	<navigation-case>
>     		<from-action>#{pooledTask.assignToCurrentActor}</from-action>
>     		<from-outcome>taskAssignedToActor</from-outcome>
>     		<to-view-id>/view/viewTRManager.jsp</to-view-id>
>     	</navigation-case>
>     </navigation-rule>
> 	
> </faces-config>
> #### web.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <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">
>     <!-- Seam -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> </web-app>
> ###
> I have seen an issue (Key: JBSEAM-347) but I don't anderstand the solution proposed or if a solution exists !
> (http://jira.jboss.org/jira/browse/JBSEAM-347)
> Thanks.
> JP.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:03:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 15 Aug 2007 10:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-995) CLONE -concurrent
 job acquirement fails
In-Reply-To: <29948611.1182451552483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17822371.1187186581563.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-995?page=comments#action_12372284 ] 
            
Ronald van Kuijk commented on JBPM-995:
---------------------------------------

cool... only a strange name for a property.... jbpm.hide...... why not CamelCasing? (me nitpicking :-) )

> CLONE -concurrent job acquirement fails
> ---------------------------------------
>
>                 Key: JBPM-995
>                 URL: http://jira.jboss.com/jira/browse/JBPM-995
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>            Reporter: Edward Staub
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>
> when more than 1 job executor thread is configured and concurrent async nodes are to be executed, it results in hibernate exceptions.
> reason: job acquirement is not synchronized well, resulting in multiple threads trying to work on the same job.
> In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been closed.  So I cloned it here..  let me know if that was incorrect process.  
> The problem was easy to reproduce, and was easy to predict in the first place.  Alex's fix (sychronize on a static class member around acquireJobs()) works for me as well.  It probably trivially improves performance, by avoiding aborted acquire attempts.
> As noted in JBPM-974, it only causes an erroneous error message being emitted - the code operates correctly.  It also makes debugging other race conditions much more difficult by injecting a lot of noise - they usually show up as stale objects as well.
> I believe the reason the trace is dumped to the log is because it's dumped at ERROR level before it even gets to JBPM, in org.hibernate.event.def.AbstractFlushingEventListener.performExecutions.  So the "catch (StaleStateException e)" doesn't suppress it - the horse has left the barn, the train has left the station, the s--t has already hit the fan - pick your favorite metaphor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:15:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 15 Aug 2007 10:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-139) Cannot add tasks to
	the task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3581063.1187187301209.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-139?page=comments#action_12372286 ] 
            
Ronald van Kuijk commented on GPD-139:
--------------------------------------

I will... just synced the latest with cvs.... give me 1 hour 

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:22:23 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 10:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4600) Rename JBossMQ
 variables from jboss-messaging to jboss.messaging-mq.lib
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17577957.1187187743447.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis closed JBAS-4600.
------------------------------------

    Resolution: Done

I've left in the renaming of mq variable and reverted the introduction of jboss messaging


> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib
> -----------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:43:06 2007
From: jira-events at lists.jboss.org (Eric Brown (JIRA))
Date: Wed, 15 Aug 2007 10:43:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1143) Migrate
 repository from CVS to SVN
In-Reply-To: <5716848.1184844227121.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7789404.1187188986219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1143?page=all ]

Eric Brown updated JBCACHE-1143:
--------------------------------

    Help Desk Ticket Reference: https://rt.corp.redhat.com/rt3/Ticket/Display.html?id=414277

> Migrate repository from CVS to SVN
> ----------------------------------
>
>                 Key: JBCACHE-1143
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1143
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:45:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 15 Aug 2007 10:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-106) xsd:attribute ref not
 supported by SchemaBinding
Message-ID: <15518233.1187189101043.JavaMail.jira@cloud.prod.atl2.jboss.com>

xsd:attribute ref not supported by SchemaBinding
------------------------------------------------

                 Key: JBXB-106
                 URL: http://jira.jboss.com/jira/browse/JBXB-106
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions:  JBossXB-2.0.0.CR2
            Reporter: Anil Saldhana
            Priority: Critical


Refer to forum for additional 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 lists.jboss.org  Wed Aug 15 10:53:11 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 10:53:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31992342.1187189591157.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1524.
------------------------------------

    Resolution: Won't Fix
      Assignee: Thomas Heute  (was: Julien Viet)

It would break the current themes for people upgrading.

And i don't really see the point, that's internal code. For developers they just have to care about header.jsp and tabs.jsp or replace the PageCustomizerInterceptor

> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 11:10:03 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 11:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3658) Remote classloading
 service - Redesign
In-Reply-To: <2583525.1158255817852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29697931.1187190603104.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-3658:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
          Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration]  (was: [Compatibility/Configuration, Documentation (Ref Guide, User Guide, etc.)])
         Assignee:     (was: Tom  Elrod)
         Priority: Major  (was: Critical)

Tom's gone.

> 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
>
> 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 lists.jboss.org  Wed Aug 15 11:16:01 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Wed, 15 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1627) Problem
 destroying service
 portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
In-Reply-To: <12607797.1186753680992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24638282.1187190961517.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Roman Kalyakin updated JBPORTAL-1627:
-------------------------------------

    Attachment: JBPORTAL-1627.patch

A small patch that fixes reloading of portal-basic-samples.

> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> ------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1627
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1627
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: JBPORTAL-1627.patch
>
>
> On AS shutdown:
> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> java.lang.reflect.UndeclaredThrowableException
>         at $Proxy0.destroy(Unknown Source)
>         at org.jboss.system.ServiceController.destroy(ServiceController.java:577)
>         at org.jboss.system.ServiceController.shutdown(ServiceController.java:714)
>         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.server.ServerImpl$ShutdownHook.shutdownServices(ServerImpl.java:1079)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1037)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
> Caused by: javax.management.InstanceNotFoundException: portal:service=ContentRenderer,type=GoogleWidgetPortletInstance is not registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:653)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
>         ... 15 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 lists.jboss.org  Wed Aug 15 11:26:03 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 15 Aug 2007 11:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17467375.1187191563994.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12372306 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

sorry for the delay.... so I discovered that what makes a difference, at least in reproducing this bug on my system, is you need to select and overwrite the value in the 'name' field on the general panel on the properties dialogue in addition to the steps listed in my original description.  If you do not change the name of the newly added task node, this error does not occurr.

Hope that helps,

cheers

Ross


> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug 15 12:10:10 2007
From: jira-events at lists.jboss.org (Kenny MacLeod (JIRA))
Date: Wed, 15 Aug 2007 12:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1711) HTMLAdaptorServlet
 updateAttributes bug?
Message-ID: <818985.1187194210318.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1711?page=comments#action_12372315 ] 
            
Kenny MacLeod commented on JBAS-1711:
-------------------------------------

18 months since last comment.  Can we add this back on the roadmap, please, it's a trivial fix.

> HTMLAdaptorServlet updateAttributes bug?
> ----------------------------------------
>
>                 Key: JBAS-1711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1711
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1
>            Reporter: SourceForge User
>            Priority: Minor
>
> SourceForge Submitter: raja05 .
> UpdateAttributes method in HtmlAdaptorServlet has a
> section of code something like
>       while( paramNames.hasMoreElements() )
>       {
>          String param = (String) paramNames.nextElement();
>          if( param.equals("name") ||
> param.equals("action") )
>             continue;
>          String value = request.getParameter(param);
>          log.trace("name="+param+", value='"+value+"'");
>          // Ignore null values, these are empty
> write-only fields
>          if( value == null || value.length() == 0 )
>             continue;
>          attributes.put(param, value);
>       }
> The check for value == null || value.length() == 0 is
> kind of wrong for my case. 
> Im trying to use a XMBean that would store the values
> from the JMX-Console to a filestore that i have created
> using Properties.load(not the
> ObjectStreamPersistenceManager but something along the
> line that uses the Property.save to store the data in a
> name=value fashion).
> The problem im getting is that if i want to clear out
> any of the attributes that have been set already, the
> above code comes to the check of value.length() == 0
> and since its blank, just moves to the next request
> param. I would like to remove this check from there so
> that even though i blank out my value, i need that to
> get persisted. 
> Please let me know if you need a detailed explanation
> or if the above is not clear
> I just need the value.length() == 0 check removed but
> not sure if thats going to cause an issue somewhere else.
> Thanks a bunch
> Raja

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 12:10:10 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 12:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-575) Join and state
 transfer violates virtual synchrony
Message-ID: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>

Join and state transfer violates virtual synchrony
--------------------------------------------------

                 Key: JGRP-575
                 URL: http://jira.jboss.com/jira/browse/JGRP-575
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.6


ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 12:20:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 12:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1711) HTMLAdaptorServlet
 updateAttributes bug?
Message-ID: <12087897.1187194801299.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I think the side effect of what you want, would be to re-set to null all values that are empty, not just the one you alter.

> HTMLAdaptorServlet updateAttributes bug?
> ----------------------------------------
>
>                 Key: JBAS-1711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1711
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1
>            Reporter: SourceForge User
>            Priority: Minor
>
> SourceForge Submitter: raja05 .
> UpdateAttributes method in HtmlAdaptorServlet has a
> section of code something like
>       while( paramNames.hasMoreElements() )
>       {
>          String param = (String) paramNames.nextElement();
>          if( param.equals("name") ||
> param.equals("action") )
>             continue;
>          String value = request.getParameter(param);
>          log.trace("name="+param+", value='"+value+"'");
>          // Ignore null values, these are empty
> write-only fields
>          if( value == null || value.length() == 0 )
>             continue;
>          attributes.put(param, value);
>       }
> The check for value == null || value.length() == 0 is
> kind of wrong for my case. 
> Im trying to use a XMBean that would store the values
> from the JMX-Console to a filestore that i have created
> using Properties.load(not the
> ObjectStreamPersistenceManager but something along the
> line that uses the Property.save to store the data in a
> name=value fashion).
> The problem im getting is that if i want to clear out
> any of the attributes that have been set already, the
> above code comes to the check of value.length() == 0
> and since its blank, just moves to the next request
> param. I would like to remove this check from there so
> that even though i blank out my value, i need that to
> get persisted. 
> Please let me know if you need a detailed explanation
> or if the above is not clear
> I just need the value.length() == 0 check removed but
> not sure if thats going to cause an issue somewhere else.
> Thanks a bunch
> Raja

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:01:01 2007
From: jira-events at lists.jboss.org (Kenny MacLeod (JIRA))
Date: Wed, 15 Aug 2007 13:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1711) HTMLAdaptorServlet
 updateAttributes bug?
Message-ID: <27087083.1187197261200.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1711?page=comments#action_12372324 ] 
            
Kenny MacLeod commented on JBAS-1711:
-------------------------------------

Yeah, OK.  I think should get fixed somehow, though, it can be quiie annoying to not be able to clear the attribute values without having to enter dummy whitespace.

> HTMLAdaptorServlet updateAttributes bug?
> ----------------------------------------
>
>                 Key: JBAS-1711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1711
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1
>            Reporter: SourceForge User
>            Priority: Minor
>
> SourceForge Submitter: raja05 .
> UpdateAttributes method in HtmlAdaptorServlet has a
> section of code something like
>       while( paramNames.hasMoreElements() )
>       {
>          String param = (String) paramNames.nextElement();
>          if( param.equals("name") ||
> param.equals("action") )
>             continue;
>          String value = request.getParameter(param);
>          log.trace("name="+param+", value='"+value+"'");
>          // Ignore null values, these are empty
> write-only fields
>          if( value == null || value.length() == 0 )
>             continue;
>          attributes.put(param, value);
>       }
> The check for value == null || value.length() == 0 is
> kind of wrong for my case. 
> Im trying to use a XMBean that would store the values
> from the JMX-Console to a filestore that i have created
> using Properties.load(not the
> ObjectStreamPersistenceManager but something along the
> line that uses the Property.save to store the data in a
> name=value fashion).
> The problem im getting is that if i want to clear out
> any of the attributes that have been set already, the
> above code comes to the check of value.length() == 0
> and since its blank, just moves to the next request
> param. I would like to remove this check from there so
> that even though i blank out my value, i need that to
> get persisted. 
> Please let me know if you need a detailed explanation
> or if the above is not clear
> I just need the value.length() == 0 check removed but
> not sure if thats going to cause an issue somewhere else.
> Thanks a bunch
> Raja

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:46:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 15 Aug 2007 13:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-792) Provide to the
 client local address of a TCP/IP connection, as seen from the server
Message-ID: <17112881.1187199961180.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide to the client local address of a TCP/IP connection, as seen from the server
-----------------------------------------------------------------------------------

                 Key: JBREM-792
                 URL: http://jira.jboss.com/jira/browse/JBREM-792
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


When org.jboss.remoting.Client.addListener() creates a callback org.jboss.remoting.transport.Connector, by default it calls InetAddress.getLocalHost().getHostAddress() to get a local address for the callback org.jboss.remoting.InvokerLocator.  If the machine happens to have multiple addresses, getLocalHost() might return the wrong one.  A solution, due to Ovidiu Feodorov, is to implement an internal invocation to which the server replies by returning the remote address of the connection over which the invocation was made.

This solution has been implemented for the socket transport (and bisocket, by inheritance) in conjunction with JBREM-781.  It should be implemented for the other transports. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:48:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-575) Join and state
 transfer violates virtual synchrony
In-Reply-To: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7906536.1187200081151.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic resolved JGRP-575.
--------------------------------------

    Resolution: Done

Change set:
ConcurrentStartupTest.java 1.23
Flush.java 1.63

> Join and state transfer violates virtual synchrony
> --------------------------------------------------
>
>                 Key: JGRP-575
>                 URL: http://jira.jboss.com/jira/browse/JGRP-575
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:50:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-575) Join and state
 transfer violates virtual synchrony
In-Reply-To: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15888546.1187200201159.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic updated JGRP-575:
-------------------------------------

    Comment: was deleted

> Join and state transfer violates virtual synchrony
> --------------------------------------------------
>
>                 Key: JGRP-575
>                 URL: http://jira.jboss.com/jira/browse/JGRP-575
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:50:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-575) Join and state
 transfer violates virtual synchrony
In-Reply-To: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21338620.1187200201284.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-575?page=comments#action_12372331 ] 
            
Vladimir Blagojevic commented on JGRP-575:
------------------------------------------

Change set:
ConcurrentStartupTest.java 1.23
FLUSH.java 1.63

> Join and state transfer violates virtual synchrony
> --------------------------------------------------
>
>                 Key: JGRP-575
>                 URL: http://jira.jboss.com/jira/browse/JGRP-575
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:55:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-236) Combine join and
	state transfer
Message-ID: <1023668.1187200501995.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic resolved JGRP-236.
--------------------------------------

    Resolution: Done

Change set:
org/jgroups/protocols/FD_SOCK.java 1.66
org/jgroups/protocols/TUNNEL.java 1.44
org/jgroups/protocols/Discovery.java 1.32
org/jgroups/protocols/LOOPBACK.java 1.25
org/jgroups/protocols/TP.java 1.150
org/jgroups/protocols/pbcast/FLUSH.java 1.62
org/jgroups/protocols/pbcast/ParticipantGmsImpl.java 1.26
org/jgroups/protocols/pbcast/GMS.java 1.110
org/jgroups/protocols/pbcast/STREAMING_STATE_TRANSFER.java 1.49
org/jgroups/protocols/pbcast/ClientGmsImpl.java 1.50
org/jgroups/protocols/pbcast/CoordGmsImpl.java 1.70
org/jgroups/protocols/pbcast/STATE_TRANSFER.java 1.72
org/jgroups/protocols/pbcast/GmsImpl.java 1.24
org/jgroups/stack/ProtocolStack.java 1.50
org/jgroups/stack/StateTransferInfo.java 1.14
org/jgroups/Event.java 1.47
org/jgroups/JChannel.java 1.141
org/jgroups/demos/Draw.java 1.46

> Combine join and state transfer
> -------------------------------
>
>                 Key: JGRP-236
>                 URL: http://jira.jboss.com/jira/browse/JGRP-236
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase.
> The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener.
> - The JOIN_REQ contains the boolean
> - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending
>   the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK),
>   we send it back to the joining member(s), and the RESUME sending 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 lists.jboss.org  Wed Aug 15 13:57:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-566) Write article about
 FLUSH and Multiplexer
In-Reply-To: <3046420.1185216587208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28664328.1187200621085.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic resolved JGRP-566.
--------------------------------------

    Resolution: Done

Article written and given to Bob for further processing.

> Write article about FLUSH and Multiplexer
> -----------------------------------------
>
>                 Key: JGRP-566
>                 URL: http://jira.jboss.com/jira/browse/JGRP-566
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> Article should target developers familiar with JGroups looking to exploit new features namely FLUSH and Multiplexer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 14:34:01 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Wed, 15 Aug 2007 14:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1085) Rule fires before
 calling fireAllRules
Message-ID: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule fires before calling fireAllRules
--------------------------------------

                 Key: JBRULES-1085
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Markus Reitz
         Assigned To: Mark Proctor


Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to

  public static void main(String ... args) {
    try {
      DroolsTest test=new DroolsTest(new File(args[0]));
      
      SpecialString first42 =new SpecialString("42");
      SpecialString second42=new SpecialString("42");
      
      System.out.println("Inserting ...");
      
      test.getSession().insert(new SpecialString("World"));
      test.getSession().insert(first42);
      test.getSession().insert(second42);

      System.out.println("Done.");
      
      System.out.println("Firing rules ...");
      
      test.getSession().fireAllRules();
      
      System.out.println("Done.");
    }
    catch (Exception ex) {
      ex.printStackTrace();
    }
  }

and using the rule

  package test

  rule "Strange rule"

    when
      not(exists(x : SpecialString() and
                 forall(y : SpecialString(this!=x)
                            SpecialString(this==y, text=="Universe"))))

    then
      System.out.println("Condition satisfied");
  end

leads to the following output:

  Condition satisfied
  Inserting ...
  Done.
  Firing rules ...
  Condition satisfied
  Done.

The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 

      System.out.println("Condition satisfied");

is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 14:41:01 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 14:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-148) NPE opening GPD
Message-ID: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE opening GPD
---------------

                 Key: GPD-148
                 URL: http://jira.jboss.com/jira/browse/GPD-148
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
            Reporter: Gavin King
         Assigned To: Koen Aers


This is with JBoss Tools beta 3.

ava.lang.NullPointerException
	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
	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:400)
	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)


The jPDL file is from the Seam DVDStore example:

<?xml version="1.0"?>

<process-definition 
	name="OrderManagement"
	xmlns="urn:jbpm.org:jpdl-3.1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
	>

    <start-state name="start">
        <transition to="approval"/>
    </start-state>

    <task-node name="approval" end-tasks="true">
        <task name="approve" description="Review order">
           <assignment pooled-actors="reviewers"/>
        </task>
        <!--
        <task name="approve">
           <assignment actor-id="manager"/>
        </task>
        -->
        <transition name="cancel"  to="cancelled"/>
        <transition name="approve" to="process"/>
        <transition name="reject"  to="cancelled"/>
    </task-node>

    <task-node name="process">
        <task name="ship" description="Ship order">
           <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
        </task>
        <transition name="shipped" to="complete">
            <action expression="#{afterShipping.log}"/>
        </transition>
    </task-node>

    <end-state name="complete"/>
    
    <end-state name="cancelled"/>
    
</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 lists.jboss.org  Wed Aug 15 14:48:01 2007
From: jira-events at lists.jboss.org (Jim Moran (JIRA))
Date: Wed, 15 Aug 2007 14:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4610) <method-attributes>
 configuration
 for MDBs in jboss.xml descriptor is not included in the dtd
Message-ID: <25944699.1187203681163.JavaMail.jira@cloud.prod.atl2.jboss.com>

<method-attributes> configuration for MDBs in jboss.xml descriptor is not included in the dtd
---------------------------------------------------------------------------------------------

                 Key: JBAS-4610
                 URL: http://jira.jboss.com/jira/browse/JBAS-4610
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB2, EJB3
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
            Reporter: Jim Moran
         Assigned To: Scott M Stark
            Priority: Minor


The jboss_4_2.dtd does not allow for <method-attributes> element and sub-elements even though support for this feature has been added in 4.2.0 per JBAS-3321

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 15:07:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 15 Aug 2007 15:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1028) Cleanup
	groupmember startup
In-Reply-To: <20025793.1186597429469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10242990.1187204821290.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1028.
--------------------------------

    Resolution: Done

> Cleanup groupmember startup
> ---------------------------
>
>                 Key: JBMESSAGING-1028
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1028
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Cleanup the group member startup so we ensure that view change precedes state arrival precedes messages.
> Add sanity checks to ensure this is the 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 lists.jboss.org  Wed Aug 15 15:17:10 2007
From: jira-events at lists.jboss.org (Anh Vuong (JIRA))
Date: Wed, 15 Aug 2007 15:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1086) InitialFact
 should not be shadowed
Message-ID: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>

InitialFact should not be shadowed
----------------------------------

                 Key: JBRULES-1086
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Anh Vuong
         Assigned To: Mark Proctor


If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:

2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
ialFactImpl
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
        at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
        at java.lang.ClassLoader.loadClass (Unknown Source)
        at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
        at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
        at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
        at org.drools.reteoo.Rete.assertObject(Rete.java:145)
        at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
        at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
        at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
        at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 15:31:01 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 15:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5051279.1187206261784.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372344 ] 
            
Gavin King commented on GPD-148:
--------------------------------

Another problem:


org.dom4j.DocumentException: Error on line 3 of document  : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity.
	at org.dom4j.io.SAXReader.read(SAXReader.java:355)
	at org.dom4j.io.SAXReader.read(SAXReader.java:271)
	at org.jbpm.gd.common.editor.AbstractContentProvider.addNotationInfo(Unknown Source)
	at org.jbpm.gd.common.editor.GraphPage.initInput(Unknown Source)
	at org.jbpm.gd.common.editor.GraphPage.init(Unknown Source)
	at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:186)
	at org.jbpm.gd.common.editor.Editor.addPage(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.initGraphPage(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
	at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:263)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2721)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:138)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:194)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:175)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:268)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:244)
	at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:50)
	at org.eclipse.ui.actions.RetargetAction.run(RetargetAction.java:220)
	at org.eclipse.ui.internal.navigator.CommonNavigatorManager$3.open(CommonNavigatorManager.java:181)
	at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:820)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
	at org.eclipse.core.runtime.Platform.run(Platform.java:857)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:46)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:193)
	at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:818)
	at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1079)
	at org.eclipse.ui.navigator.CommonViewer.handleOpen(CommonViewer.java:353)
	at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1183)
	at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:263)
	at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:257)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:297)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Control.sendTrackEvents(Control.java:2734)
	at org.eclipse.swt.widgets.Control.kEventControlTrack(Control.java:1953)
	at org.eclipse.swt.widgets.Widget.controlProc(Widget.java:367)
	at org.eclipse.swt.widgets.Display.controlProc(Display.java:835)
	at org.eclipse.swt.internal.carbon.OS.CallNextEventHandler(Native Method)
	at org.eclipse.swt.widgets.Tree.kEventMouseDown(Tree.java:2363)
	at org.eclipse.swt.widgets.Widget.mouseProc(Widget.java:1262)
	at org.eclipse.swt.widgets.Display.mouseProc(Display.java:2817)
	at org.eclipse.swt.internal.carbon.OS.SendEventToEventTarget(Native Method)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2936)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)

This is with the following pageflow file:

<pageflow-definition	
	xmlns="http://jboss.com/products/seam/pageflow"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation=
	    "http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-2.0.xsd" 
	name="numberGuess">
   
   <start-page name="displayGuess" view-id="/numberGuess.jsp">
      <redirect/>
      <transition name="guess" to="drools"/>
   </start-page>
  
   <decision name="drools">

      <handler class="org.jboss.seam.drools.DroolsDecisionHandler">
         <workingMemoryName>workingMemory</workingMemoryName>
         <assertObjects>
            <element>#{game}</element>
            <element>#{guess}</element>
         </assertObjects>
      </handler>

      <transition to="displayGuess"/>
      <transition name="lose" to="lose"/>
      <transition name="win" to="win"/>
      
   </decision>
   
   <page name="win" view-id="/win.jsp">
   	  <end-conversation />
      <redirect/>
   </page>
   
   <page name="lose" view-id="/lose.jsp">
      <end-conversation />
      <redirect/>
   </page>
   
</pageflow-definition>


> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:33:01 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 15:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32022255.1187206381157.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372345 ] 
            
Gavin King commented on GPD-148:
--------------------------------

Excuse me. The second problem is with the following pageflow:


<pageflow-definition 
	xmlns="http://jboss.com/products/seam/pageflow"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation=
	    "http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-2.0.xsd"
	name="numberGuess">
   
   <start-page name="displayGuess" view-id="/numberGuess.jspx">
      <redirect/>
      <transition name="guess" to="evaluateGuess">
         <action expression="#{numberGuess.guess}"/>
      </transition>
      <transition name="giveup" to="giveup"/>
      <transition name="cheat" to="cheat"/>
   </start-page>
   
   <decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">
      <transition name="true" to="win"/>
      <transition name="false" to="evaluateRemainingGuesses"/>
   </decision>
   
   <decision name="evaluateRemainingGuesses" expression="#{numberGuess.lastGuess}">
      <transition name="true" to="lose"/>
      <transition name="false" to="displayGuess"/>
   </decision>
   
   <page name="giveup" view-id="/giveup.jspx">
      <redirect/>
      <transition name="yes" to="lose"/>
      <transition name="no" to="displayGuess"/>
   </page>
   
   <process-state name="cheat">
      <sub-process name="cheat"/>
      <transition to="displayGuess"/>
   </process-state>

   <page name="win" view-id="/win.jspx">
      <end-conversation/>
      <redirect/>
   </page>
   
   <page name="lose" view-id="/lose.jspx">
      <end-conversation/>
      <redirect/>
   </page>
   
</pageflow-definition>


> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:41:20 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 15:41:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21748512.1187206880875.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372348 ] 
            
Koen Aers commented on GPD-148:
-------------------------------

Gavin, I assume there is also a file with graphical information. Can you specify these as well?

> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:52:18 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 15:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31997980.1187207538739.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372350 ] 
            
Gavin King commented on GPD-148:
--------------------------------

You mean a .gpd file?

I deleted them, to get a "fresh start".

> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:58:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 15:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <490833.1187207881286.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372352 ] 
            
Koen Aers commented on GPD-148:
-------------------------------

The first problem is probably due to the comment, which is apparently not handled appropriately.
I'll track down the other problem and try to fix both tomorrow.

> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 16:25:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Aug 2007 16:25:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
In-Reply-To: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20352839.1187209519569.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry updated JBAS-4593:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116213

Opened a forum thread with some preliminary diagnostic info.

> Leak in org/jboss/mx/loading/UnifiedClassLoader3
> ------------------------------------------------
>
>                 Key: JBAS-4593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Scott M Stark
>
> [description pasted from support case]
> After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:
> found a path to the target: 26093 (depth: 5)
> 0 0 Heap root
> 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
> 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
> 160611 0 Instance: [Ljava/lang/Object;
> 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
> 217357 0 Instance: Ljavax/management/Notification;
> 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;
> So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.
> Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 16:51:01 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Wed, 15 Aug 2007 16:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1087) Context Assistant
 that shows list of filtered DSL does not work on DRL editor
Message-ID: <8059624.1187211061284.JavaMail.jira@cloud.prod.atl2.jboss.com>

Context Assistant that shows list of filtered DSL does not work on DRL editor
-----------------------------------------------------------------------------

                 Key: JBRULES-1087
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1087
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
         Environment: Windows 2000, Drools 4.0, Eclipse 3.2.2
            Reporter: Joe Son
         Assigned To: Mark Proctor
             Fix For:  4.0.0.GA



DRL FILE:
package rules
 
import com.nationwide.pc.rules.TrexoWrapUC40;
 
expander UC40Dsl.dsl
rule	"Neither Correct Or Complete Audit For High AP"
	salience 1800
	activation-group "UC40"
	when
		UC40 has
		- additional prem >= 25000.0 Or returned premium >= 5000.0
		- task type != "Correct Audit"
		- task type != "Complete Audit Review"
	then
		Set RuleResult "Verify Audit Accuracy"
		Log result "Verify Audit Accuracy"
		Dispatch work item
end

On previous versions, the context assistant show the list of DSL mappings available for me to use.  This one, it doesn't.  When I type - followed by Cntr+Space it sounds a windows error sound.

When I simply type Cntr+Space, it shows list of DRL keywords plust my imported class 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 lists.jboss.org  Wed Aug 15 18:07:01 2007
From: jira-events at lists.jboss.org (Jeff Wang (JIRA))
Date: Wed, 15 Aug 2007 18:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-139) Cannot add tasks to
	the task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5441749.1187215621334.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-139?page=comments#action_12372379 ] 
            
Jeff Wang commented on GPD-139:
-------------------------------

It looks like this is fixed in the 3.1 release candidate.  

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 18:09:01 2007
From: jira-events at lists.jboss.org (Jeff Wang (JIRA))
Date: Wed, 15 Aug 2007 18:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-149) Creating tasks by
 editing XML source will prevent the XML file from being re-opened
Message-ID: <5015540.1187215741100.JavaMail.jira@cloud.prod.atl2.jboss.com>

Creating tasks by editing XML source will prevent the XML file from being re-opened
-----------------------------------------------------------------------------------

                 Key: GPD-149
                 URL: http://jira.jboss.com/jira/browse/GPD-149
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: Eclipse 3.3, Designer 3.1.0 CR
            Reporter: Jeff Wang
         Assigned To: Koen Aers


When you create new tasks by editing the source, it will break the process definition and not allow you to re-open it in Eclipse.

Steps to recreate:

1) Create a new process definition
2) Create a task node using the GUI
3) Switch to the source tab
4) Copy the task xml tag
5) Rename the task name to something unique
6) Close the file
7) Re-open using the JBPM editor



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 18:55:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 18:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1543350.1187218501640.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1614.
------------------------------------

    Resolution: Done

Resolved, thanks for reporting this issue !

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 18:55:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 18:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15702549.1187218502107.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1614:
-----------------------------------

    Fix Version/s: 2.8 Final

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 19:19:11 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 15 Aug 2007 19:19:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5543457.1187219951527.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4422?page=comments#action_12372390 ] 
            
Richard Achmatowicz commented on JBAS-4422:
-------------------------------------------

1. Twiddle is a command line tool which allows sending MBeanServer commands to an application server and receiving the results. 
Twiddle has a -s <hostname> option. Using this option tells Twiddle to use that hostname when doing a JNDI lookup to get the MBeanServerConnection proxy it needs to communicate with the MBeanServer. 
Use of the -s option to cause JNDI to do a lookup on the testsuite AS instance node0 was commented out in TwiddleUnitTestCase:

     if (isWindows())
     {
        command.add("cmd");
        command.add("/C");
        command.add("twiddle");
        //command.add("-s");
        //command.add(getServerHost());
        command.addAll(Arrays.asList(args));
     }
     else
     {
        command.add("/bin/sh");
        command.add("-c");
        String twiddleCmd = "./twiddle.sh ";
        //twiddleCmd += "-s ";
        //twiddleCmd += getServerHost();
        twiddleCmd += makeTwiddleArgs(args);
        command.add(twiddleCmd);
     }

Reinstating the -s option fixes the problem with the test case, as the command getServerHost() returns the correct name for the host on which the AS was started (e.g. localhost, or 192.23.1.21), the JNDI lookup succeeds, the MBeanServerConnection proxy is obtained, and the MBeanServerCommand is executed.

I have checked this on Windows.

  


> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Stan Silvert
>            Priority: Trivial
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Wed Aug 15 19:19:11 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 19:19:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4445299.1187219951716.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372391 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

Barry - what do you mean by testing a rule? My take on this is that in different environments you have different rules included/excluded (not just different versions of rules) - my point of confusion is how this can work? How do you isolate testing to just a rule or rules - aren't you testing the system behaviour as a whole? 

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 19:39:01 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 15 Aug 2007 19:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27271866.1187221141086.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4422?page=comments#action_12372396 ] 
            
Richard Achmatowicz commented on JBAS-4422:
-------------------------------------------

2. What is more interesting is explaining why TwiddleUnitTestCase, with the -s still commented out, was passing on RHEL and HPUX, but failing on Windows and Solaris. This was the state of affairs in AS 4.2 RC7. 
In that case, the AS testsuite was started using the parameters:
-u to specify an alternate multicast address (instead of the default 230.0.0.4) 
-node0 to specify the binding to a local IP address (insterad of the default localhost)

The TwiddleUnitTestCase, without the -s option, would in the first instance try to connect to JNDI using localhost:1099. Because no AS was bound to that host/port, the connection would fail. Then, JNDI
autodiscovery would send out a multicast message on 230.0.0.4:1102 to see if any AS instances were listening on that address. Because the testsuite was started with the -u option, the AS instance running as part of the testsuite would be listening for multiucast messages on a multicast address other than 230.0.0.4, but on the same port 1102. On Windows and Solaris, in order for a multicast message to be correctly received, both the address and the port on the message must match the address and the port which the receiver is listening on.
Thus, in the case of Windows (and Solaris), the mulicast messages were not received by the AS instance started by the testsuite, auto-discovery failed, and the TwiddleUnitTestCase could not succeed in obtaining an MBeanServerConnection to any AS instance, and so the test failed.

On the other hand, when the same test was run on RHEL and HPUX, the same sequence of events occurred, up to the point at which autodiscovery was initiated. But due to the "bug" in RHEL and HPUX, for a multicast message to be received by a receiver, only the multicast message port and the multicast receiver port need match, despite any differences in multicast address (contact Brian Stansberry for more details!). The multicast message was thus received, the AS instance offered itself as a JNDI server, the MBeanServerConnection was retrieved by the TwiddleUnitTestCase, and the test passed.

That is my understanding of why the test passed on RHEL and HPUX, but failed on Solaris and Windows.

    

> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Stan Silvert
>            Priority: Trivial
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Wed Aug 15 19:43:01 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 15 Aug 2007 19:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9842559.1187221381261.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4422?page=comments#action_12372400 ] 
            
Richard Achmatowicz commented on JBAS-4422:
-------------------------------------------

In any case, it looks as though the -s option should be reinstated, as this is a test of Twiddle's ability to process MBean operations, and not a test of JNDI auto-discovery in a twiddle context.

I'll make the change and test all platforms tomorrow.


> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Stan Silvert
>            Priority: Trivial
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Wed Aug 15 21:17:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1039) Add Number Guess
 example with Rule Flow
In-Reply-To: <21507599.1185671567073.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12298301.1187227021278.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1039.
---------------------------------

    Resolution: Done

> Add Number Guess example with Rule Flow
> ---------------------------------------
>
>                 Key: JBRULES-1039
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1039
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Create a number guess example, similar to Seams example, but with text input.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:19:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30374718.1187227141167.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

completion seems to work now, can we close this off now?

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Wed Aug 15 21:19:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1064) "->" notation for
 predicates missing in documentation
In-Reply-To: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28249885.1187227141497.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1064.
---------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

> "->" notation for predicates missing in documentation
> -----------------------------------------------------
>
>                 Key: JBRULES-1064
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> the notation "->" for adressing complex terms is missing from 4.0.0 documentation.
> It has been "return value operator" in 3.0.6:
> <quoted from 3.0.6>
> Example 3.13. Return Value operator
> Person( girlAge : age, sex = "F" )
> Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
> </quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:21:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25588337.1187227261334.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1081.
---------------------------------

    Resolution: Rejected

Not a bug

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>            Priority: Minor
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:21:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9150471.1187227261531.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1083:
----------------------------------

    Fix Version/s: 4.0.1

> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:21:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7764042.1187227261935.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1076:
----------------------------------

    Fix Version/s: 4.0.1

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Wed Aug 15 21:23:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1020) BRMS Custom Rule
 Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13253067.1187227393751.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1020:
----------------------------------

    Fix Version/s: 4.0.1

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 21:23:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6365424.1187227393908.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1086:
----------------------------------

    Fix Version/s: 4.0.1

> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:23:14 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:23:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1085) Rule fires before
 calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20145772.1187227394090.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1085:
----------------------------------

    Fix Version/s: 4.0.1

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:25:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1079) Problem with "!="
 field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21224299.1187227501299.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1079:
----------------------------------

    Fix Version/s: 4.0.1

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Wed Aug 15 21:25:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10019544.1187227501848.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I've left this open as Edson thinks he can make it check the field name on the class in this situation.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 15 21:25:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1065) Unable to return
 Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9411161.1187227502012.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1065:
----------------------------------

    Fix Version/s: 4.0.1

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 15 21:25:02 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1028) importing .brxml
 into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26155441.1187227502282.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1028:
----------------------------------

    Fix Version/s: 4.0.1

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Wed Aug 15 21:27:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18939101.1187227621366.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1053:
----------------------------------

    Fix Version/s: 4.0.1

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:27:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1023) Typing the
 parameter to be replace by DSL/DRL replacement
In-Reply-To: <30190376.1184942567175.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31590509.1187227621593.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1023:
----------------------------------

    Fix Version/s: FUTURE

> Typing the parameter to be replace by DSL/DRL replacement
> ---------------------------------------------------------
>
>                 Key: JBRULES-1023
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1023
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: christian bastin
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> We have a very long DSL including more 150 diff?rent lines (wich could be very similar). We have no posibility to be sure of the replacement operarted by the parsing.  We often dicover problem that force us to move the order of the lines in the DSL. This is an simple example of what I think could be improved.
>  
> If you have a DSL
> test {code} is {value}
> this could replace this 2 rules in the DRL
> rule "Rule-1"
> 	when
> 		test 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> rule "Rule-1"
> 	when
> 		test 10 + 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> I would like the ability to type the parameter of my DSL, for example with regular expression.
> test {code|[0-9]+} is {value|[0-9]+}
> so the only rule available for replacement should be the first rule ("Rule-1").  The other rule would not find a replacement and should be implemented in the DSL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Aug 15 21:31:05 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11405800.1187227865904.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1054:
----------------------------------

        Fix Version/s: 4.0.1
    Affects Version/s:  4.0.0.GA
                           (was: 4.0.1)

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Wed Aug 15 21:31:06 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8101889.1187227866525.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1055:
----------------------------------

    Fix Version/s: 4.0.1

> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:31:06 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1066)
 org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not
 serializable
In-Reply-To: <23034283.1186562329494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5160081.1187227866684.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1066:
----------------------------------

    Fix Version/s: 4.0.1

> org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not serializable
> ---------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1066
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1066
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: seam cvs (2007-08-05), which includes drools 4.0.0.GA, I believe
>            Reporter: Matt Drees
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> I sometimes get a java.io.NotSerializableException: org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction when restarting my seam webapp.  It seems that the problem is simply that WorkingMemoryReteAssertAction doesn't implement Serializable.  This email (http://osdir.com/ml/java.drools.user/2006-12/msg00163.html) seems to indicate that it should, but it apparently hasn't been 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 lists.jboss.org  Wed Aug 15 21:31:07 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1071)
 BinaryRuleBaseLoader doesn't accept custom ClassLoader
In-Reply-To: <2403729.1186687983991.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30694257.1187227867080.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1071:
----------------------------------

    Fix Version/s: 4.0.1

> BinaryRuleBaseLoader doesn't accept custom ClassLoader
> ------------------------------------------------------
>
>                 Key: JBRULES-1071
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1071
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Vladimir Schafer
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> AddPackage method of class BinaryRuleBaseLoader accepts custom classloader as a parameter, but this isn't propagated to DroolsObjectInputStream in addPackage method call. So custom class loading isn't available when constructing RuleBases from JBRMS packaged files.
> Error is in file org.drools.util.BinaryRuleBaseLoader.java, Core module, line 81. Code ObjectInputStream oin = new DroolsObjectInputStream( in ); should be changed to ObjectInputStream oin = new DroolsObjectInputStream( in, classLoader ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:33:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1087) Context Assistant
 that shows list of filtered DSL does not work on DRL editor
In-Reply-To: <8059624.1187211061284.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6477458.1187227981160.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1087.
---------------------------------

    Fix Version/s: 4.0.1
                       (was:  4.0.0.GA)
       Resolution: Done

This we already discussed this and its because the file is not named .dslr, which I believe you already have working now.

> Context Assistant that shows list of filtered DSL does not work on DRL editor
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1087
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1087
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>         Environment: Windows 2000, Drools 4.0, Eclipse 3.2.2
>            Reporter: Joe Son
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> DRL FILE:
> package rules
>  
> import com.nationwide.pc.rules.TrexoWrapUC40;
>  
> expander UC40Dsl.dsl
> rule	"Neither Correct Or Complete Audit For High AP"
> 	salience 1800
> 	activation-group "UC40"
> 	when
> 		UC40 has
> 		- additional prem >= 25000.0 Or returned premium >= 5000.0
> 		- task type != "Correct Audit"
> 		- task type != "Complete Audit Review"
> 	then
> 		Set RuleResult "Verify Audit Accuracy"
> 		Log result "Verify Audit Accuracy"
> 		Dispatch work item
> end
> On previous versions, the context assistant show the list of DSL mappings available for me to use.  This one, it doesn't.  When I type - followed by Cntr+Space it sounds a windows error sound.
> When I simply type Cntr+Space, it shows list of DRL keywords plust my imported class 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 lists.jboss.org  Wed Aug 15 21:37:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1066)
 org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not
 serializable
In-Reply-To: <23034283.1186562329494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <366238.1187228221179.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1066.
---------------------------------

    Resolution: Done

> org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not serializable
> ---------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1066
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1066
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: seam cvs (2007-08-05), which includes drools 4.0.0.GA, I believe
>            Reporter: Matt Drees
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> I sometimes get a java.io.NotSerializableException: org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction when restarting my seam webapp.  It seems that the problem is simply that WorkingMemoryReteAssertAction doesn't implement Serializable.  This email (http://osdir.com/ml/java.drools.user/2006-12/msg00163.html) seems to indicate that it should, but it apparently hasn't been 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 lists.jboss.org  Wed Aug 15 21:41:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1071)
 BinaryRuleBaseLoader doesn't accept custom ClassLoader
In-Reply-To: <2403729.1186687983991.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13307364.1187228461124.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1071.
---------------------------------

    Resolution: Done

> BinaryRuleBaseLoader doesn't accept custom ClassLoader
> ------------------------------------------------------
>
>                 Key: JBRULES-1071
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1071
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Vladimir Schafer
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> AddPackage method of class BinaryRuleBaseLoader accepts custom classloader as a parameter, but this isn't propagated to DroolsObjectInputStream in addPackage method call. So custom class loading isn't available when constructing RuleBases from JBRMS packaged files.
> Error is in file org.drools.util.BinaryRuleBaseLoader.java, Core module, line 81. Code ObjectInputStream oin = new DroolsObjectInputStream( in ); should be changed to ObjectInputStream oin = new DroolsObjectInputStream( in, classLoader ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:43:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33500037.1187228581163.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1054:
----------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Wed Aug 15 21:43:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6874359.1187228581362.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1055:
----------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:45:24 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20173715.1187228724906.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

wierd as Rete node clearly stops InitialFactImpl from being shadowed:
            String pkgName = (pkg != null) ? pkg.getName() : "";
            if ( "org.drools.reteoo".equals( pkgName ) || "org.drools.base".equals( pkgName ) ) {
                // We don't shadow internal classes
                this.shadowEnabled = false;
                this.shadowClass = null;
                this.instantiator = null;
                return;
            }


> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:47:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1052) When Inserting
 a fact cannot set a String field
In-Reply-To: <1292464.1185911829398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11582327.1187228821419.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I don't think I see this now in the latest trunk, has someone fixed this? Can someone else verify and close this.

> When Inserting a fact cannot set a String field
> -----------------------------------------------
>
>                 Key: JBRULES-1052
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1052
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> A String field only let me put in numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:52:01 2007
From: jira-events at lists.jboss.org (Tong Lee (JIRA))
Date: Wed, 15 Aug 2007 21:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11897630.1187229121223.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12372426 ] 
            
Tong Lee commented on JBRULES-1065:
-----------------------------------

Thank you so much Mark!!!

The feature we were looking for is the example below from the blog...
  http://blog.athico.com/2007/05/jboss-rules-expressiveness-goes-to-next.html
  Cheese( newPrice == ( oldPrice * 1.10 ) )

We're going live next month and we would love to use this feature even if we have to use the Milestone Release.  Please update this thread when there is a milestone build for us to try.

Thanks again...


> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 15 22:10:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <732391.1187230201128.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372430 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

How are the rules marked as "tested" and who sets the effective dates for testing? is it manual? 

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:35:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33337627.1187231701113.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372434 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

One idea on how to do this as an advanced feature: 

 have a config file on the classpath that specifies the selectors available. They are a class that implements certain interfaces. Out of the box there are none, but if you add one in, then you can choose it in the GUI when you go to build a package (it will show up a list of them, you pick the appropriate one) - that allows users to define them in any way they see fit. 

This does NOT however address fields that don't currently exist (like tested dates etc).

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:37:19 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:37:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1020) BRMS Custom Rule
 Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7414232.1187231839607.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale updated JBRULES-1020:
-----------------------------------

    Comment: was deleted

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:37:19 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:37:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25058697.1187231839800.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372435 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

One idea on how to do this as an advanced feature:

 have a config file on the classpath that specifies the selectors available. They are a class that implements certain interfaces. Out of the box there are none, but if you add one in, then you can choose it in the GUI when you go to build a package (it will show up a list of them, you pick the appropriate one) - that allows users to define them in any way they see fit.

This does NOT however address fields that don't currently exist (like tested dates etc).

Optionally, could provide a drop down of status boxes, and perhaps a selector for categories or other attributes to filter purely in the GUI (however that will not automate things, just provide a GUI to choose from).

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:37:20 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:37:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1036) dialect errors
 if after import declarations
In-Reply-To: <1942890.1185648467658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17298969.1187231840083.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1036:
--------------------------------------

    Assignee: Michael Neale  (was: Edson Tirelli)

> dialect errors if after import declarations
> -------------------------------------------
>
>                 Key: JBRULES-1036
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1036
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> In the Shopping example if I have the dialect after the imports it 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 lists.jboss.org  Wed Aug 15 22:53:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1023) Typing the
 parameter to be replace by DSL/DRL replacement
In-Reply-To: <30190376.1184942567175.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20937615.1187232781170.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1023:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

This is a nice to have, but for 4.2 at the earliest.

> Typing the parameter to be replace by DSL/DRL replacement
> ---------------------------------------------------------
>
>                 Key: JBRULES-1023
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1023
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: christian bastin
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> We have a very long DSL including more 150 diff?rent lines (wich could be very similar). We have no posibility to be sure of the replacement operarted by the parsing.  We often dicover problem that force us to move the order of the lines in the DSL. This is an simple example of what I think could be improved.
>  
> If you have a DSL
> test {code} is {value}
> this could replace this 2 rules in the DRL
> rule "Rule-1"
> 	when
> 		test 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> rule "Rule-1"
> 	when
> 		test 10 + 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> I would like the ability to type the parameter of my DSL, for example with regular expression.
> test {code|[0-9]+} is {value|[0-9]+}
> so the only rule available for replacement should be the first rule ("Rule-1").  The other rule would not find a replacement and should be implemented in the DSL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Aug 15 23:03:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:03:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1085) Rule fires
 before calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4624951.1187233393609.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

With latest trunk code I couldn't replicate this. I have added the test to our generation integration tests and enhanced it. 
See testNestedCorelatedRulesWithForall
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/test/java/org/drools/integrationtests/FirstOrderLogicTest.java
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/test/resources/org/drools/integrationtests/test_NestedCorrelatedRulesWithForall.drl

to verify this yourself please do try the latest snapshot from the URL here:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 23:03:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:03:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1085) Rule fires before
 calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13108598.1187233393779.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1085.
---------------------------------

    Resolution: Done

I'll assume this was a bug in 4.0 and is now fixed.

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 23:17:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25743368.1187234221286.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

You'll get a full cross product. I changed it from two 42 numbers to a 42 and a 42. here is my output, which is correct.
43[org.drools.SpecialString at 111b910]/42[org.drools.SpecialString at e79839]
42[org.drools.SpecialString at e79839]/43[org.drools.SpecialString at 111b910]
World[org.drools.SpecialString at 1d36dfe]/43[org.drools.SpecialString at 111b910]
43[org.drools.SpecialString at 111b910]/World[org.drools.SpecialString at 1d36dfe]
42[org.drools.SpecialString at e79839]/World[org.drools.SpecialString at 1d36dfe]
World[org.drools.SpecialString at 1d36dfe]/42[org.drools.SpecialString at e79839]

Which is what you would expect you have 3 different objects and its going to produce all possible cross procuts, only the this!=x stops it producing a cross product with identity equals objects for x and y.

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Wed Aug 15 23:19:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1079) Problem with "!="
 field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22553527.1187234341125.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1079.
---------------------------------

    Resolution: Rejected

Could not reproduce

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Wed Aug 15 23:52:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33092166.1187236321269.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I couldn't reproduce this but added this as an itnegration test anyway. see MiscTest.testCrossProductRemovingIdentityEquals()

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Thu Aug 16 00:27:21 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 00:27:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1028) importing .brxml
 into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14474700.1187238441294.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1028:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

Fer - we can add some smarts to an existing method (or have a new method) that will take BRXML (ie convert it to DRL and then do it as normal). 

This is for 4.0.1 definately.

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Thu Aug 16 00:29:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 00:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1054) DSL-Editor:
 "Add" button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1845283.1187238541167.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1054:
--------------------------------------

    Assignee: Fernando Meyer  (was: Michael Neale)

This is a bug in the IDE

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Thu Aug 16 00:31:26 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 00:31:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9751849.1187238686532.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1076:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 01:56:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 01:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-576) X509Token cannot be
	created
Message-ID: <2173136.1187243761072.JavaMail.jira@cloud.prod.atl2.jboss.com>

X509Token cannot be created
---------------------------

                 Key: JGRP-576
                 URL: http://jira.jboss.com/jira/browse/JGRP-576
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5.1, 2.6


[from Andre Luckow]
I tried to setup a JGroups stack using the AUTH protocol in conjunction
with a X509Token authentication. The protocol stack worked fine before.
After adding the AUTH layer, I received the following error:

2007-08-15 16:40:01,742 ERROR protocols.TCP [Incoming
Thread,AisReplicationGroup,192.168.0.2:8800,run:1445] failed handling
incoming message
java.io.EOFException
        at java.io.DataInputStream.readFully(DataInputStream.java:178)
        at java.io.DataInputStream.readUTF(DataInputStream.java:565)
        at java.io.DataInputStream.readUTF(DataInputStream.java:522)
        at org.jgroups.Message.readFrom(Message.java:737)
        at org.jgroups.protocols.TP.readMessage(TP.java:1214)
        at org.jgroups.protocols.TP.access$700(TP.java:49)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1439)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)

It seems that the getName() method of the X509Token class returns the
wrong classname it should be:

  public String getName() {
        return "org.jgroups.auth.X509Token";
    }

instead of "org.jgroups.auth.X509Token1_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 lists.jboss.org  Thu Aug 16 01:59:17 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 01:59:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-576) X509Token cannot be
	created
In-Reply-To: <2173136.1187243761072.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27336682.1187243957684.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-576.
---------------------------

    Resolution: Done

> X509Token cannot be created
> ---------------------------
>
>                 Key: JGRP-576
>                 URL: http://jira.jboss.com/jira/browse/JGRP-576
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> [from Andre Luckow]
> I tried to setup a JGroups stack using the AUTH protocol in conjunction
> with a X509Token authentication. The protocol stack worked fine before.
> After adding the AUTH layer, I received the following error:
> 2007-08-15 16:40:01,742 ERROR protocols.TCP [Incoming
> Thread,AisReplicationGroup,192.168.0.2:8800,run:1445] failed handling
> incoming message
> java.io.EOFException
>         at java.io.DataInputStream.readFully(DataInputStream.java:178)
>         at java.io.DataInputStream.readUTF(DataInputStream.java:565)
>         at java.io.DataInputStream.readUTF(DataInputStream.java:522)
>         at org.jgroups.Message.readFrom(Message.java:737)
>         at org.jgroups.protocols.TP.readMessage(TP.java:1214)
>         at org.jgroups.protocols.TP.access$700(TP.java:49)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1439)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>         at java.lang.Thread.run(Thread.java:595)
> It seems that the getName() method of the X509Token class returns the
> wrong classname it should be:
>   public String getName() {
>         return "org.jgroups.auth.X509Token";
>     }
> instead of "org.jgroups.auth.X509Token1_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 lists.jboss.org  Thu Aug 16 02:47:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 02:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1088) Spelling check on
	docs
Message-ID: <32085040.1187246821199.JavaMail.jira@cloud.prod.atl2.jboss.com>

Spelling check on docs 
-----------------------

                 Key: JBRULES-1088
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1088
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Fernando Meyer
         Assigned To: Fernando Meyer
             Fix For: 4.0.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 lists.jboss.org  Thu Aug 16 02:55:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 16 Aug 2007 02:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-139) Cannot add tasks to the
	task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16123774.1187247301309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-139?page=all ]

Koen Aers closed GPD-139.
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

OK Thanks, I am closing it

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 02:59:01 2007
From: jira-events at lists.jboss.org (Arsalan Zaidi (JIRA))
Date: Thu, 16 Aug 2007 02:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1089) Getting "could
 not access property ('=')" for a valid rule.
Message-ID: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>

Getting "could not access property ('=')" for a valid rule.
-----------------------------------------------------------

                 Key: JBRULES-1089
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
            Reporter: Arsalan Zaidi
         Assigned To: Mark Proctor


From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
Sent: 13 August 2007 22:16
To: Rules Users List
Subject: Re: [rules-users] could not access property ('=')

Attachments: ATT426765.txt


   This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?

   Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 





when

           $dto : DTO( )

           W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1


then



   Thanks, and hope it helps.

   Edson



2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
  Hi.



  I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.



  I have a rule which looks like this:



  rule "W250.42 Editable"

        when

              DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )

        then

              System.out.println ("0" );

              Action action = createAction("W250.42" , false , true );

              retList.add(action); 

  end 





  both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .



  Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.



  org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47

        at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )

        at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )

        at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )

        at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )

        at org.drools.reteoo.Rete.assertObject(Rete.java:168 )

        at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 

        at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )

        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )

        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )

        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )

        at com.sample.DroolsTest.main( DroolsTest.java:34)

  Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )

        at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )

        at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )

        at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)

        at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 

        at org.mvel.MVEL.executeExpression( MVEL.java:202)

        at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )

        at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )

        ... 10 more

  Caused by: org.mvel.PropertyAccessException: could not access property ('=') 

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )

        ... 18 more



  If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.



  I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')



  What seems to be the issue?



  Thanks in advance!



  Regards,



  --Arsalan

        This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 

       

  _______________________________________________
  rules-users mailing list
  rules-users at lists.jboss.org 
  https://lists.jboss.org/mailman/listinfo/rules-users





-- 
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.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 lists.jboss.org  Thu Aug 16 03:01:05 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Thu, 16 Aug 2007 03:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <86500.1187247665943.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372455 ] 
            
Antoine Herzog commented on JBPORTAL-1524:
------------------------------------------

On my opinion : 

"It would break the current themes for people upgrading" : the sooner, the better : later, it will be "to late, there are to many people relying on ...

This code is introducing a "special way of building a region of the page".
It uses a "region", but it is not using a Portlet

very confusing when looking at all this 
not easy to search (grep) thing in the code, with only "dashboard" as key word

"internal code", "developers they just have to care about" :
for out of the box, and for mini customization.

from my experience : for any real portal in prod in a company, the dev + prod people will not just care only about changing a JSP.
They want to see what is going on in this part of the screen, and especially on the login feature.

well, all this is not vital.... it will work out of the box.
My proposal is to help dev people to have :
 - a quicker understanding of how all this work
 - a better way to customize this... as I needed first place 

help customize... help to make portal for prod.



> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 03:06:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 03:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
Message-ID: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: join rejection won't be received because UNICAST drops it
---------------------------------------------------------------

                 Key: JGRP-577
                 URL: http://jira.jboss.com/jira/browse/JGRP-577
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5.1, 2.6


When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Thu Aug 16 03:10:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 03:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11000064.1187248201213.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-577.
---------------------------

    Resolution: Done

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Thu Aug 16 03:22:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 03:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1036) dialect errors if
 after import declarations
In-Reply-To: <1942890.1185648467658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3783677.1187248921746.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-1036.
----------------------------------

    Resolution: Done

> dialect errors if after import declarations
> -------------------------------------------
>
>                 Key: JBRULES-1036
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1036
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> In the Shopping example if I have the dialect after the imports it 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 lists.jboss.org  Thu Aug 16 03:38:13 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 03:38:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32241979.1187249893235.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1076?page=comments#action_12372462 ] 
            
Fernando Meyer commented on JBRULES-1076:
-----------------------------------------

I just corrected both maven wrong references as well the operation word. 

about you confusing compiling the source, after download some project from subversion in implicit that you must cding into the downloaded folder, but of course I can explicitly say that; about the 100MB download its the eclipse distro plus some plug ins to build and test the drools eclipse IDE as you can  see the eclipse and documentation optional to build drools from trunk

just type
C:\dev\jbossrules\> mvn clean install





> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 03:40:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 03:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27455656.1187250001237.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer resolved JBRULES-1076.
-------------------------------------

    Resolution: Done

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 03:42:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 03:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32707335.1187250121128.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372463 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

OK I think I have a general simple solution:

When building a package, we have a choice to either build the lot, or enter a custom selector criteria (which may be either a SQL style predicate - or an EL expression - haven't decided yet). There can be some buttons to create some sample ones for the common cases. 

however, this does NOT remember any past selectors as entered (only the browser memory will) - but I can't see a way around that unless we create another place to store these "preferences" or selectors for running again at a future time (which seems overkill). 

That or we can allow admins to configure a properties file with a fixed list of selectors to choose from - which option sounds better? 


> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 16 03:52:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 03:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31462516.1187250721536.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372469 ] 
            
Thomas Heute commented on JBPORTAL-1524:
----------------------------------------


"It would break the current themes for people upgrading" : the sooner, the better : later, it will be "to late, there are to many people relying on ...

It's already the case. We cannot break compatibility in 2.6 branch and 2.8 should benefit from a new engine for this.

There are several levels of customization, just modifying the jsps (from my experience it helps a lot of users, but of course not the people who have a visual identity), modifying the layout, and modifying the PageCustomizerInterceptor.

I don't see what the login feature has to do with that, we are talking about "looking pretty"

I will have another look at your code (next time, *please* send a diff, it's easier to look at)  because i really didn't see the benefits specially in terms of customization (except changing the name of those special regions, that appear anywhere else and is documented (i think)). (understanding the code is relative, and doesn't justify a breaking change)


> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 03:58:01 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 16 Aug 2007 03:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4611) HTTP Session Repl
 Cache configured with CacheLoader can cause slow AS shutdowns
Message-ID: <26411619.1187251081159.JavaMail.jira@cloud.prod.atl2.jboss.com>

HTTP Session Repl Cache configured with CacheLoader can cause slow AS shutdowns
-------------------------------------------------------------------------------

                 Key: JBAS-4611
                 URL: http://jira.jboss.com/jira/browse/JBAS-4611
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, JBoss Cache, Web (Tomcat) service
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Galder Zamarreno
         Assigned To: Brian Stansberry
            Priority: Minor


When AS stops, the sessions for that web app are evicted from memory, 
which means removing from the memory locally. We still need the sessions
 in other nodes, for example if we're bringing a node down for maintenance 
in which case, we don't want to remove sessions of the cluster completely. 
We want users to failover to another node and continue as normal.

The code handling this evictions first removes any data in these sessions and
 then tries to check whether this HTTP session has any children nodes in the
 cache so that it can do a complete clearout of the subtree:

JBossCacheWrapper:

   void evictSubtree(Fqn fqn)
   {

      Exception ex = null;
      for (int i = 0; i < RETRY; i++)
      {
         try
         {
            // Evict the node itself first, since if it stores a Pojo
            // that will do everything
            proxy_.evict(fqn);

            // next do a depth first removal; this ensure all nodes
            // are removed, not just their data map
            Set children = proxy_.getChildrenNames(fqn);
...

If no cache loaders were used, this would be fine, it wouldn't find any 
children in memory and would return quickly. A true local call. 
However, for a customer who's using a ClusteredCacheLoader to get around 
some state transfer issues, when AS discovers that this session does 
not contain any children nodes, it goes remote to find them because 
it didn't find them locally (won't find them remotely either):

CacheLoaderInterceptor:

   private boolean mustLoad(DataNode n, Object key)
   {
      return n == null ||
              (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key)));
   }

As the node has been emptied, CLI (CacheLoaderInterceptor) thinks it 
needs to go remote. Same thing would happen with Pojo too (as the 
entire node is emptied). This is an unnecessary trip which is delaying 
the local eviction of sessions.

This would happen regardless of the CacheLoader used.

Two possible solutions come to my mind:
- easy one: call getChildrenNames() before evict and cache in a local variable the 
children Set. getChildrenNames() would land locally cos the fqn exists yet.
- complex one: do a getChildrenNames(Option) passing an option indicating that 
if the lookup fails locally, don't bother going remote.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 04:58:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 16 Aug 2007 04:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-200) Make sure the
 batch and sh files work
Message-ID: <29893530.1187254681124.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-200?page=comments#action_12372474 ] 
            
Stale Pedersen commented on JBAOP-200:
--------------------------------------

changed the classpath import so it would include all jars.
the .sh files where tested against the 2.0.0alpha5 release. need to verify that the .bat files also works before i can close this...

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:12:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1035) Potential
	security issue
In-Reply-To: <6455963.1186598569318.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21845519.1187255521044.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1035.
--------------------------------

    Resolution: Rejected

AFAICT there is nothing to fix here

> Potential security issue
> ------------------------
>
>                 Key: JBMESSAGING-1035
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1035
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Need to investigate whether there is an issue here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:20:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2232310.1187256001071.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-1026:
---------------------------------

        Summary: Ensure successfull test run against all supported databases  (was: Ensure successfull test run against all supported databases, also DB2)
    Description: Postgresql, MySQL, Sybase, Oracle, MSSQL

> Ensure successfull test run against all supported databases
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Postgresql, MySQL, Sybase, Oracle, MSSQL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1090) Simple data field
 enums in BRMS
Message-ID: <21981533.1187257381183.JavaMail.jira@cloud.prod.atl2.jboss.com>

Simple data field enums in BRMS
-------------------------------

                 Key: JBRULES-1090
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1090
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Michael Neale
             Fix For: 4.0.1


Can use MVEL (or something) to store (as a discrete asset) a mapping of fact/fields to value lists. Then these value lists can be used in the Guided editor. 

eg:

Person.age : [1, 2, 3, 4, 5, 6, 7]
Person.sex: [M, F]
Person.classification: [ HIGH, LOW]

these are then used to drive drop downs. 

For extra bonus points, provide a means to display a different value to what is rendered. 
This can then be loaded as a separate map into SCE and loaded up to the client for display as 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 lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1049) Exceptions in
 logs after clustering test run
Message-ID: <28422090.1187257381307.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exceptions in logs after clustering test run
--------------------------------------------

                 Key: JBMESSAGING-1049
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1049
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.GA


After running clustering tests, several exceptions are found in the logs.

These seem innocuous since the test suite passes but we should investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1028) importing
 .brxml into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31463136.1187257381601.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=comments#action_12372479 ] 
            
Michael Neale commented on JBRULES-1028:
----------------------------------------

Fer - perhaps a better way is to update the drools-ant project to be able to deal with all the asset types (basically do what the BRMS ContentPackageAssembler does - but with files) - this would be FAR SUPERIOUR and we can integrate it with the IDE later as well.

ping me with any Q's.

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1632) Impossible to
 deactivate registration in WSRP producer configuration.
Message-ID: <1352609.1187257381672.JavaMail.jira@cloud.prod.atl2.jboss.com>

Impossible to deactivate registration in WSRP producer configuration.
---------------------------------------------------------------------

                 Key: JBPORTAL-1632
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1632
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.2 Final, 2.8 Final


Empty producer-configuration is not authorized in the DTD, in particular.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:47:01 2007
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 16 Aug 2007 05:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-184) Parsing more
	than one file
In-Reply-To: <18498056.1183400157724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22375172.1187257621340.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ales Justin reassigned JBMICROCONT-184:
---------------------------------------

    Assignee: Ales Justin

> Parsing more than one file
> --------------------------
>
>                 Key: JBMICROCONT-184
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-184
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>             Fix For: JBossMC-2.0.0.CR1
>
>
> The AbstractVFSParser has the following limitiation:
>    @Override
>    protected T parse(DeploymentUnit unit, String name, String suffix, T root) throws Exception
>    {
>       // Should we include the deployment
>       // The infrastructure will only check leafs anyway so no need to check here
>       if (name == null && isIncludeDeploymentFile())
>          name = unit.getName();
>       
>       // Try to find the metadata
>       VFSDeploymentUnit vfsDeploymentUnit = (VFSDeploymentUnit) unit;
>       List<VirtualFile> files = vfsDeploymentUnit.getMetaDataFiles(name, suffix);
>       if (files.size() == 0)
>          return null;
>       
>       // TODO remove this limitation
>       if (files.size() > 1)
>          throw new DeploymentException("Only one file is allowed, found=" + files);
>       VirtualFile file = files.get(0);
> This is really also related to the "reparse" that is done for ejb-jar.xml/jboss.xml and [jboss-]web.xml
> There should be parsing deployers that know how to parse multiple files into one object 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 lists.jboss.org  Thu Aug 16 05:52:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1050) Replace usage
 of oswego concurrent with java.util.concurrent
Message-ID: <28748024.1187257921046.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace usage of oswego concurrent with java.util.concurrent
------------------------------------------------------------

                 Key: JBMESSAGING-1050
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1050
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 1


Now we are Java 5 or later only, we should get rid of all oswego concurrent usage and use java.util.concurrent 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 lists.jboss.org  Thu Aug 16 06:00:01 2007
From: jira-events at lists.jboss.org (Barry Knapp (JIRA))
Date: Thu, 16 Aug 2007 06:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14626304.1187258401345.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372483 ] 
            
Barry Knapp commented on JBRULES-1020:
--------------------------------------


My Definition of Rule Testing:   Testing new rule with existing rules that will be in production with the new rule, in a systems integrated environment.

Here is an example, I have a production server with 100 rules and a rule #1 that says if Driver Age < 21 then set Fact Risky Driver

Due to some change in company policy, I need to replace this rule #1  with 2 new rules.

Rule #2 : if Driver Age < 21 and Driver has no accidents then set Fact Young Driver
Rule #3 : if Driver Age < 21 and Driver has >0 accidents then set Fact Risky Driver


I would need an Integration test environment to test Rule #2 and Rule #3 with all the other 99 production rules, but Rule #1 should not be included in the test environment, since my intention is for Rules #2 and #3 to replace Rule #1.

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 16 06:09:01 2007
From: jira-events at lists.jboss.org (Barry Knapp (JIRA))
Date: Thu, 16 Aug 2007 06:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16015263.1187258941125.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372484 ] 
            
Barry Knapp commented on JBRULES-1020:
--------------------------------------

> How are the rules marked as "tested" and who sets the effective dates for testing? is it manual?

The rules will be manually updated with "Tested", Effective Date, Expiration Date, Test Effective Date and Test Expiration Date by the business user.  In the long run I would like to automate the tested flag to true when the snapshot containing that rule is deployed to the test environment, but no time for that right now.  :-)
[ Show ? ]
Michael Neale [15/Aug/07 10:09 PM] How are the rules marked as "tested" and who sets the effective dates for testing? is it manual?

> have a config file on the classpath that specifies the selectors available. They are a class that implements certain interfaces. Out of the box there
> are none, but if you add one in, then you can choose it in the GUI when you go to build a package (it will show up a list of them, you pick the
> appropriate one) - that allows users to define them in any way they see fit.
> This does NOT however address fields that don't currently exist (like tested dates etc).

This would probably work well for me, since the application will give my class control where I can look up in a custom database table or repository extension for my custom rule properties and values.


> That or we can allow admins to configure a properties file with a fixed list of selectors to choose from - which option sounds better?

The admin configuration of the properties file would be perfect.  The selective deployment script are tightly tied to the rule management process and rule life cycle.  These will be defined one time by IT and probably see little change after that.


> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 16 06:49:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 16 Aug 2007 06:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4606) Hypersonic server
 mode TCP socket problem
In-Reply-To: <5093937.1187090041430.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26132182.1187261341501.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Adrian Brock closed JBAS-4606.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Dimitris Andreadis)

This is NOT a JBoss bug.

The underlying cause is a hypersonic error message, raise the issue on that project.

Caused by: java.sql.SQLException: socket creation error
        at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
        at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
        at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
        at org.hsqldb.jdbcDriver.connect(Unknown Source) 

Configuration of thirdparty software within JBoss should be raised in the forums
as help requests NOT as bug reports.

> Hypersonic server mode TCP socket problem
> -----------------------------------------
>
>                 Key: JBAS-4606
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4606
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: Sun JVM, x86_64&i686, RHEL5, JBossAS conf. "default", running as service jbossas.
>            Reporter: Martin Vecera
>
> I wanted to deploy Duke's bank J2EE example. This requires HSQLDB in server mode. The server/deploy/hsqldb-ds.xml is well prepared for switching HSQLDB to server mode, so I did it. This XML file uses ${jboss.bind.address} property to determine HSQLDB binding address.
> I was running JBossAS with 'service jbossas start'. In /etc/sysconfig/jbossas I had JBOSS_IP=127.0.0.1.
> I got the following error:
> 2007-08-14 13:27:30,715 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
> org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:179)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
>         at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
>         at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
>         at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
>         at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
>         at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
>         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 org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         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 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 $Proxy42.start(Unknown Source)
>         at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
>         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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:508)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.sql.SQLException: socket creation error
>         at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
>         at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
>         at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
>         at org.hsqldb.jdbcDriver.connect(Unknown Source)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
>         ... 122 more
> When I replaced the {$jboss.bind.address} (both occurences in hsqldb-ds.xml) with 'localhost' everything was OK.
> So I tried to replace it with 127.0.0.1 and got the same error.
> Then I tried to put the ${jboss.bind.address} property back and changed JBOSS_IP in /etc/sysconfig/jbossas to 'localhost'.
> Well, everything was working then.
> So I returned JBOSS_IP=127.0.0.1 back and voila - everything is OK!!!
> I tried it twice on two different machines. Once I used JBOSS_IP=localhost I was able to use any of the previously mentioned configuration and it was working. VERY STRANGE! After each change I restarted JBossAS completely.
> I tried nslookup at the beginning to see if it is bound corectly:
> [root at xen61 deploy]# nslookup 127.0.0.1
> Server:         10.34.32.125
> Address:        10.34.32.125#53
> 1.0.0.127.in-addr.arpa  name = localhost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 06:52:13 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Thu, 16 Aug 2007 06:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3002189.1187261533098.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372489 ] 
            
Antoine Herzog commented on JBPORTAL-1524:
------------------------------------------

ok
what do you call "send a diff"
what tool ?

> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 07:17:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 07:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14616408.1187263021590.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372494 ] 
            
Thomas Heute commented on JBPORTAL-1524:
----------------------------------------

SVN does it if you got the source from SVN

"svn diff"

or simply the "diff" command line on linux (or Cygwin) 

"diff -rub theUntouchedDirectory myDirectory"

r for recusrive
u for unified
b to ignore the changes in number of spaces

or other tools available of Windows (i don't know them but i found the diff tool here: http://gnuwin32.sourceforge.net/packages/diffutils.htm)



> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 07:30:14 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 07:30:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1540) Add description
 column to portlet lists
In-Reply-To: <12933516.1183739992920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15118662.1187263814057.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1540.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

> Add description column to portlet lists
> ---------------------------------------
>
>                 Key: JBPORTAL-1540
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1540
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final, 2.6 Final
>            Reporter: Chris Laprun
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: Picture 3.png
>
>
> With WSRP, Portlets don't always have a useful name, resulting in less than useful portlet lists... See attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 07:54:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 07:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1608) CMS content
 type always display with no decoration
In-Reply-To: <3650382.1185258947112.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15212464.1187265241050.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1608.
------------------------------------

    Fix Version/s: 2.8 Final
       Resolution: Done

> CMS content type always display with no decoration
> --------------------------------------------------
>
>                 Key: JBPORTAL-1608
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1608
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Changing window properties has no 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 lists.jboss.org  Thu Aug 16 08:14:17 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Thu, 16 Aug 2007 08:14:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
Message-ID: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException when the 'result' block of an 'accumulate' function returns null
-------------------------------------------------------------------------------------

                 Key: JBRULES-1091
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Alexandre Gattiker
         Assigned To: Mark Proctor


java.lang.NullPointerException
	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
	at com.sample.DroolsTest.main(DroolsTest.java:28)


Example rule:
rule "Example"
	no-loop true
	when
		$d:		Double()
		from accumulate ( m : Message( $value: status ),
                              init( double total = 0; ),
                              action( System.out.println($value); ),
                              result( null )
                         )
	then
		System.out.println( "xx"); 
		
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 lists.jboss.org  Thu Aug 16 08:18:01 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Thu, 16 Aug 2007 08:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1092) Invalid Java code
 generated from 'accumulate' function with nested classes
Message-ID: <22762348.1187266681169.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invalid Java code generated from 'accumulate' function with nested classes
--------------------------------------------------------------------------

                 Key: JBRULES-1092
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1092
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Alexandre Gattiker
         Assigned To: Mark Proctor


Steps to reproduce:
- Create a sample new project with the Eclipse plugin
- Add following rule to the .drl file
- Execute DroolsTest

rule "AccumulateTest"
	no-loop true
	when
		$d: Double()
		from accumulate ( m : Message( $value: status ),
                              init( double total = 0; ),
                              action( total += $status ),
                              result( total )
                         )
	then
		System.out.println( "ok" ); 
		
end

Exception is:
org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=AccumulateTest, agendaGroup=MAIN, salience=0, no-loop=true]
	com/sample/Rule_AccumulateTest_0.java (27:834) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
	com/sample/Rule_AccumulateTest_0.java (27:869) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
	com/sample/Rule_AccumulateTest_0.java (29:1027) : Syntax error, insert ";" to complete Statement
	com/sample/Rule_AccumulateTest_0.java (29:1027) : $status cannot be resolved
	com/sample/Rule_AccumulateTest_0.java (39:1483) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
	com/sample/Rule_AccumulateTest_0.java (39:1518) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name

	at org.drools.rule.Package.checkValidity(Package.java:408)
	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
	at com.sample.DroolsTest.readRule(DroolsTest.java:64)
	at com.sample.DroolsTest.main(DroolsTest.java:21)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 09:45:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 16 Aug 2007 09:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-103) JBossXB ignores
 non-ignorable white space
In-Reply-To: <20632248.1181214195060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5420982.1187271901533.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Alexey Loubyansky updated JBXB-103:
-----------------------------------

    Affects Version/s:  JBossXB-2.0.0.CR2
                       JBossXB-1.0.0.CR10

> JBossXB ignores non-ignorable white space
> -----------------------------------------
>
>                 Key: JBXB-103
>                 URL: http://jira.jboss.com/jira/browse/JBXB-103
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR10,  JBossXB-2.0.0.CR2
>            Reporter: Carlo de Wolf
>         Assigned To: Alexey Loubyansky
>         Attachments: unit-test.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 lists.jboss.org  Thu Aug 16 09:49:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 16 Aug 2007 09:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-103) JBossXB ignores
 non-ignorable white space
In-Reply-To: <20632248.1181214195060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15930909.1187272141769.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Alexey Loubyansky closed JBXB-103.
----------------------------------

    Fix Version/s: JBossXB-2.0.0.CR4
                   JBossXB-1.0.0.CR11
       Resolution: Done

Fixed.

> JBossXB ignores non-ignorable white space
> -----------------------------------------
>
>                 Key: JBXB-103
>                 URL: http://jira.jboss.com/jira/browse/JBXB-103
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR10,  JBossXB-2.0.0.CR2
>            Reporter: Carlo de Wolf
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-2.0.0.CR4, JBossXB-1.0.0.CR11
>
>         Attachments: unit-test.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 lists.jboss.org  Thu Aug 16 10:41:02 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 10:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-567) Add one shot state
 transfer for multiple substates
In-Reply-To: <15276236.1185217071282.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3596151.1187275262467.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic updated JGRP-567:
-------------------------------------

    Comment: was deleted

> Add one shot state transfer for multiple substates
> --------------------------------------------------
>
>                 Key: JGRP-567
>                 URL: http://jira.jboss.com/jira/browse/JGRP-567
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.x
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> Currently (<= 2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is:
> public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 10:41:02 2007
From: jira-events at lists.jboss.org (Satya Satyamoorthy (JIRA))
Date: Thu, 16 Aug 2007 10:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1041) jBPM documentation
 changes to include Deployment and Debug steps.
Message-ID: <21593965.1187275262652.JavaMail.jira@cloud.prod.atl2.jboss.com>

jBPM documentation changes to include Deployment and Debug steps.
-----------------------------------------------------------------

                 Key: JBPM-1041
                 URL: http://jira.jboss.com/jira/browse/JBPM-1041
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Documentation
    Affects Versions: jBPM GPD 3.0.7
         Environment: All
            Reporter: Satya Satyamoorthy
         Assigned To: Tom Baeyens
             Fix For: jBPM GPD 3.0.7


Please add adequate documentation listing the steps to 
1. Deploy the processes to different environments - such as test, user acceptance, production etc. from the RHDS.
2. Set breakpoints and Trace and 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 lists.jboss.org  Thu Aug 16 11:41:01 2007
From: jira-events at lists.jboss.org (Andy Pemberton (JIRA))
Date: Thu, 16 Aug 2007 11:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25811573.1187278861382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372553 ] 
            
Andy Pemberton commented on JBPORTAL-1631:
------------------------------------------

Thomas:

First, I want to mention that I really enjoy JBoss Portal and appreciate all the hard work by you and your team. My company is actively and successfully using JBoss Portal on several client projects. Because I enjoy the product, I have a vested interest in its success in the market.

So - back to the discussion at hand: while I do see some value in targeting CSS to specific user-agents, I also see problems with this approach. 

(a) Typically, this approach relies on the user-agent string from a HTTP header. The problem with this approach is that the user-agent string can be changed and is done so quite frequently. In short, the user-agent string is not a reliable indicator of the client's browser (see: https://addons.mozilla.org/en-US/firefox/addon/59).

(b) A bigger problem, however, is that targeting CSS to particular user agents creates maintainability problems. 
	Example: If I target CSS to FireFox 2 now, the release of FireFox 3 may require that I change/redeploy my code? 
	Example: If I target CSS to IE as a whole (not to a specific version) because of a particular defect in IE7, what happens if this defect gets resolved with IE8? (This was all too often the case with IE6 and IE7).
	Example: Managing separate style sheets for each browser requiring support is a worst case scenario, but *quite* a head-ache

Instead, CSS should be written according to the W3 CSS specifications; either user agents will support a given CSS feature (selector, pseudo-class, etc.) or not.
	-Targeting CSS to particular browsers is counter-productive given the goal of standards-compliant CSS and HTML. 
	-So rather than targeting CSS to a specific web browser, the CSS should be implicitly targeted based on support for a given CSS feature.

Having said that, you might wonder - isn't IE's conditional comment system an example of targeting CSS to a specific user agent?

Well, yes and no. 

Yes - conditional comments *do* target CSS specifically to (or from) IE. So, this is a maintainability problem as noted in point B above. However, because of the specific CSS defects caused by IE's lack of support for W3 standards (see: http://www.positioniseverything.net/, http://www.satzansatz.de/cssd/onhavinglayout.html), targeting CSS to this browser is acceptable and IMHO necessary. Most of the other widely used, modern browsers/rendering engines (Gecko, WebCore, Presto) support the CSS specs to a degree that in almost all cases, targeting specific style sheets to these browsers is not necessary. 

No - Conditional comments are not like traditional CSS user agent targeting, however, because they do not rely on the user-agent HTTP header. Typically, conditional comments are used to send additional CSS rules to IE to override rules set for all other browsers. Basically, it's kind of like punishing IE for not supporting the CSS standards. This means that we *don't* have to manage separate style sheets for all browsers/versions - just for this versions of IE requiring fixes. 

So, Conditional Comments do not have problem A and problem B is an acceptable consequence of the *need* to target CSS to IE. 

For these reasons I think that a module in JBoss Portal that targets CSS to user agents is actually (a) over-architecting the solution and (b) leading away from the standards-compliant nature that JBoss Portal should push for. I think supporting conditional comments alone is the right approach for JBoss Portal.

-----

BTW: I'm not a Microsoft/IE basher. IE7 greatly enhanced its standards support for CSS and HTML. The fact is that a lot of folks still use IE6, which has limited support for CSS/HTML standards.


> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 11:41:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1153) Introduce a
 concept of structural nodes
In-Reply-To: <6252571.1185539387065.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29342151.1187278861503.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1153?page=comments#action_12372554 ] 
            
Manik Surtani commented on JBCACHE-1153:
----------------------------------------

Identified by a boolean flag on the node?

> Introduce a concept of structural nodes
> ---------------------------------------
>
>                 Key: JBCACHE-1153
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1153
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Structural nodes should not be taken into consideration when processing regions for eviction.
> Typically are nodes that do not contain data (and are not intended to contain data), but are used to build 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 lists.jboss.org  Thu Aug 16 11:43:21 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Thu, 16 Aug 2007 11:43:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8427313.1187279001846.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dave Dibble closed JBRULES-1076.
--------------------------------


Fernando,

Appreciate your patience and help. Maven, subversion, and ant are all new to me, so am learning what is assumed in their use while Jboss Rules is my primary interest. In following along in the manual, the subversion download did show the current directory, but the 'mvn' command in 3.4.1 did not, so I don't feel like a complete dork for not realizing it.  Again, thanks. (Am back on my way.)

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 11:46:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-971) Eviction policy
 based on adaptive replacement
In-Reply-To: <27209315.1171014930036.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31055605.1187279161201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-971?page=all ]

Manik Surtani updated JBCACHE-971:
----------------------------------

    Fix Version/s: 3.0.0
                       (was: 2.1.0.GA)

> Eviction policy based on adaptive replacement
> ---------------------------------------------
>
>                 Key: JBCACHE-971
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-971
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 3.0.0
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Quote from Mircea Markus:
> There is an eviction policy algorithm more efficient than LRU (which I found quite popular) - Adaptive Replacement Policy. The basic idea is to not rely only on the time of last access to the node, but also on the number of time(frequency) a given node was accessed. Here it is a nice description of how it works: http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 11:46:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-1154) Introduce
 ability to mark
 nodes as immortal - i.e., they never get considered for eviction
In-Reply-To: <19979184.1185539627066.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8638178.1187279161340.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1154?page=all ]

Manik Surtani reassigned JBCACHE-1154:
--------------------------------------

    Assignee: Mircea Markus  (was: Manik Surtani)

> Introduce ability to mark nodes as immortal - i.e., they never get considered for eviction
> ------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 11:48:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-1153) Introduce a
 concept of structural nodes
In-Reply-To: <6252571.1185539387065.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12149677.1187279281063.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1153?page=all ]

Manik Surtani reassigned JBCACHE-1153:
--------------------------------------

    Assignee: Mircea Markus  (was: Manik Surtani)

> Introduce a concept of structural nodes
> ---------------------------------------
>
>                 Key: JBCACHE-1153
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1153
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>
> Structural nodes should not be taken into consideration when processing regions for eviction.
> Typically are nodes that do not contain data (and are not intended to contain data), but are used to build 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 lists.jboss.org  Thu Aug 16 12:15:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Aug 2007 12:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-395) Add support for
 overriding getResources method in java.lang.ClassLoader
Message-ID: <17729683.1187280901159.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for overriding getResources method in java.lang.ClassLoader
-----------------------------------------------------------------------

                 Key: JBBUILD-395
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-395
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


The jboss-test project has a class called
org.jboss.test.classloader.FilteringClassLoader

This class overrides the method getResources(String) in java.lang.Classloader.  This is fine for jdk1.5, but this method is declared final in jdk1.4.  There should be a way to retro translate this to maintain this behaviour in jdk1.4.  Maybe the overriding method should just be removed when the retro translation takes place.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 12:19:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Aug 2007 12:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-396) Add support for
 Thread.UncaughtExceptionHandler
Message-ID: <21567461.1187281141341.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for Thread.UncaughtExceptionHandler
-----------------------------------------------

                 Key: JBBUILD-396
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-396
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


The jboss-test project uses the jdk1.5 class Thread.UncaughtExceptionHandler.
Retro should translate this class to something compatible with jdk14

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 12:39:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Aug 2007 12:39:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <16904980.1187282359967.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic reopened JBAS-2299:
-----------------------------------

             

> 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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Thu Aug 16 12:39:20 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Aug 2007 12:39:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <17051241.1187282360647.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.2.2.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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Thu Aug 16 12:41:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Aug 2007 12:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2299) OutOfMemory error when
 repetatively deploying and undeploying with 10 minute interval
Message-ID: <30234851.1187282461795.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBAS-2299.
---------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
       Resolution: Rejected

> 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
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Thu Aug 16 13:38:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 13:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
Message-ID: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
-----------------------------------------------------------------------------------------------------

                 Key: JBPM-1042
                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: jBPM 3.2.1
Java 1.6 update 2
Windows XP
Run as a standalone Java application. No app server.
Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
            Reporter: Jeff Johnson
         Assigned To: Tom Baeyens


org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".

My ActionHandler.execute() method: 
    public void execute(ExecutionContext executionContext) throws Exception
    {
      // Normally would do stuff here
      // Leave via the default transition
      // When this test case was written, this method would throw when 
      // it tried to enter Node2 because it would try to lock the token but 
      // it is already locked.
      executionContext.leaveNode();
    }
  }

Section 9.5 of the user guide states: "Note the difference
between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.

The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.

// From org.jbpm.graph.def.Node.execute()
public void execute(ExecutionContext executionContext) {
    // if there is a custom action associated with this node
    if (action!=null) {
      try {
        // execute the action
        executeAction(action, executionContext);

      } catch (Exception exception) {
        // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
        // search for an exception handler or throw to the client
        raiseException(exception, executionContext);
      }

    } else {
      // let this node handle the token
      // the default behaviour is to leave the node over the default transition.
      leave(executionContext);
    }
  }

However this appears to conflict with the comments for Token.lock()
 /**
   * locks a process instance for further execution.  A locked token 
   * cannot continue execution.  This is a non-persistent
   * operation.  This is used to prevent tokens being propagated during 
   * the execution of actions.
   * @see #unlock(String) 
   */
  public void lock(String lockOwnerId) {


Originally this test case failed in jBPM 3.2.1 with the following exception
 * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
  at org.jbpm.graph.exe.Token.lock(Token.java:646)
  at org.jbpm.graph.def.Node.enter(Node.java:316)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
  at org.jbpm.graph.def.Transition.take(Transition.java:151)
  at org.jbpm.graph.def.Node.leave(Node.java:393)
  at org.jbpm.graph.def.Node.leave(Node.java:357)
  at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
  at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
  at org.jbpm.graph.def.Action.execute(Action.java:122)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
  at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
  at org.jbpm.graph.def.Node.execute(Node.java:338)
  at org.jbpm.graph.def.Node.enter(Node.java:318)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
  at org.jbpm.graph.def.Transition.take(Transition.java:151)
  at org.jbpm.graph.def.Node.leave(Node.java:393)
  at org.jbpm.graph.node.StartState.leave(StartState.java:70)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
  at org.jbpm.graph.exe.Token.signal(Token.java:194)
  at org.jbpm.graph.exe.Token.signal(Token.java:139)
  at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
  at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
  at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
  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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
  at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 13:40:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 13:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <102211.1187286001108.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Jeff Johnson updated JBPM-1042:
-------------------------------

    Attachment: SimpleAsyncProcessTest.java

Test case this produces describe exception. Initially written to work with jBPM 3.2.1 code base.

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 13:42:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 13:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8518082.1187286121305.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Jeff Johnson updated JBPM-1042:
-------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4074927#4074927

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 14:13:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 14:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14567134.1187287981266.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reopened JBRULES-1079:
------------------------------------

             
Reproduced the problem.

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Thu Aug 16 14:21:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 14:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21449979.1187288461387.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-1079.
------------------------------------

    Resolution: Done

I was able to reproduce the problem. It was a problem related to the shadow fact generated equals() method. The method was being generated like this:

   public boolean equals( Object object ) {
       if ( this == object || 
            this.delegate == object || 
            this.delegate.equals( object ) ) {
 
            return true;
       }
 
       if (( object == null ) || ( ! ( object instanceof <class> ) ) ) 
            return false;
 
       if( object instanceof ShadowProxy && 
          ( this.delegate == ((ShadowProxy)object).delegate ||
            this.delegate.equals( ((ShadowProxy)object).delegate ) ) ) {
 
            return true;
 
       }
 
       <class> other = (<class>) object;
 
       // for each field:
 
           if ( ! _fieldIsSet ) {
               __field = this.delegate.method();
                __fieldIsSet = true;
           }
 
           // for primitive types
           if ( this.field != other.field ) 
                return false;
 
           // for non primitive types
           if( ( ( this.field == null ) && ( other.field != null ) ) ||
               ( ( this.field != null ) && ( ! this.field.equals( other.field ) ) ) )
                return false;
 
       // if all fields were ok
       return true;
       // or if no fields exists
       return false;
    }

I.e, after failing on previous checks, the shadow fact tried to compare the value for each field, and in case they were all equal, it returned true, causing the unexpected behavior when fields were set to the "42" value in your test.

I removed that part from the equals() method generation and now it is like this:

   public boolean equals( Object object ) {
       if ( this == object || 
            this.delegate == object || 
            this.delegate.equals( object ) ) {
 
            return true;
       }
 
       if (( object == null ) || ( ! ( object instanceof <class> ) ) ) 
            return false;
 
       if( object instanceof ShadowProxy && 
          ( this.delegate == ((ShadowProxy)object).delegate ||
            this.delegate.equals( ((ShadowProxy)object).delegate ) ) ) {
 
            return true;
 
       }
      return false;
  }

As all tests are green, I'm giving it a go and committing.
Please let us know if it fixes your problems.

Thanks for reporting and providing test case.


> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Thu Aug 16 14:30:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 14:30:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1085) Rule fires
 before calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23219688.1187289019938.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1085?page=comments#action_12372597 ] 
            
Edson Tirelli commented on JBRULES-1085:
----------------------------------------

I tried this with 4.0GA and was not able to reproduce it either.

If it is still a problem for you, can you please attach a self contained test in a zip file to this ticket? 


> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 14:59:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 14:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17234766.1187290741320.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372601 ] 
            
Thomas Heute commented on JBPORTAL-1631:
----------------------------------------

a) anything in the header can be false, but what the point ? This is not a security issue. You can also lie to the IE conditional comments.

b) no, i am not necessarly talking about a simple mapping, but regular expressions, and default to some stylesheet anyway.
"CSS should be written according to the W3 CSS specifications;" it reminds me an idea of julien to write this standard CSS and create a compiler for different browser but that's a big project as a whole :) (any contributor interested ?)

"isn't IE's conditional comment system an example of targeting CSS to a specific user agent? "

You read in my mind :)

>From my experience i agree that other browser support the standards in a better way but still, you have different behavior even on the same version of FF on Windows or Linux (try the dashboard DnD to have that confirmation). Also you may want a stylesheet for Opera on a computer and Opera on a Nintendo Wii.


Again, the idea is to allow rules like:

If (user-agent is IE <5.5) use CSS a
If (user-agent is IE = 6) use CSS b
If (user-agent is another version of IE) use CSS c
If (user-agent is opera on a wii) use CSS d
otherwise use CSS e

That said, this is not done, but really i think it's the cleaner way. Who knows what Microsoft will decide for IE8 maybe they will stop supporting conditional comments.

I also hate IE ;)



> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:07:10 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 15:07:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1094)
 PackageBuilderConfiguration.setDialectConfiguration() method is not
 correctly setting dialect configurations
Message-ID: <21869476.1187291230433.JavaMail.jira@cloud.prod.atl2.jboss.com>

PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect configurations
------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1094
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1094
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect 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 lists.jboss.org  Thu Aug 16 15:15:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 15:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-491) Multiplexer should
 execute getState for all registered MuxChannel under one FLUSH phase
In-Reply-To: <13148506.1177600470196.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8948693.1187291701605.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic resolved JGRP-491.
--------------------------------------

    Resolution: Done

Change set:
JChannel.java 1.143
Multiplexer.java 1.64
FLUSH.java 1.64
STATE_TRANSFER.java 1.73
STREAMING_STATE_TRANSFER.java 1.50
StateTransferInfo.java 1.15



> Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-491
>                 URL: http://jira.jboss.com/jira/browse/JGRP-491
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5, 2.4.1
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> The idea behind MuxChannel state transfer listeners is to trigger all state transfers together and have all or none result for all registered MuxChannels. As currently implemented underlying plumbing with will trigger each transfer under *separate* FLUSH. In order to have it done under one flush we have to do manual flushing in Multiplexer (startFlush/stopFlush) for these transfers T and we should retrofit FLUSH protocol *not to* trigger flushing for each GET_STATE from T. We have two options:
> a) add requireFlush field in StateTransferInfo - that is then passed down with GET_STATE
> - this requires changing signature of JChannel.getState
> b) retrofit FLUSH to detect special handling of GET_STATE
> - at state requester A we record that we requested GET_STATE and if another GET_STATE arrives from A while channel is already flushed do not trigger another 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 lists.jboss.org  Thu Aug 16 15:21:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 15:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-567) Add one shot state
 transfer for multiple substates
In-Reply-To: <15276236.1185217071282.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27683608.1187292061342.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic updated JGRP-567:
-------------------------------------

    Fix Version/s: 3.0
                       (was: 2.6)

We will do this one together with [JGRP-536]

> Add one shot state transfer for multiple substates
> --------------------------------------------------
>
>                 Key: JGRP-567
>                 URL: http://jira.jboss.com/jira/browse/JGRP-567
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.x
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 3.0
>
>
> Currently (<= 2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is:
> public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:21:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 15:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-567) Add one shot state
 transfer for multiple substates
In-Reply-To: <15276236.1185217071282.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24163984.1187292061483.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Vladimir Blagojevic updated JGRP-567:
-------------------------------------

    Comment: was deleted

> Add one shot state transfer for multiple substates
> --------------------------------------------------
>
>                 Key: JGRP-567
>                 URL: http://jira.jboss.com/jira/browse/JGRP-567
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.x
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 3.0
>
>
> Currently (<= 2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is:
> public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:23:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 15:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1094)
 PackageBuilderConfiguration.setDialectConfiguration() method is not
 correctly setting dialect configurations
In-Reply-To: <21869476.1187291230433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26855056.1187292181319.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1094.
----------------------------------

    Resolution: Done

Fixed.

> PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect configurations
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1094
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1094
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect 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 lists.jboss.org  Thu Aug 16 15:25:17 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 16 Aug 2007 15:25:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32582608.1187292317801.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372610 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

I'm inclined to close this issue since it is a symptom of the other issues. Does not add anything new to what is already known. Comments?

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:38:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 15:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1088) Spelling check
	on docs
In-Reply-To: <32085040.1187246821199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9947909.1187293081101.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer resolved JBRULES-1088.
-------------------------------------

    Resolution: Done

> Spelling check on docs 
> -----------------------
>
>                 Key: JBRULES-1088
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1088
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Fernando Meyer
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 16 15:44:05 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 16 Aug 2007 15:44:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1095) Deserializing
 Package Objects Consumes Large Amount of Memory
Message-ID: <17599698.1187293445172.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deserializing Package Objects Consumes Large Amount of Memory
-------------------------------------------------------------

                 Key: JBRULES-1095
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1095
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows
            Reporter: Ming Jin
         Assigned To: Mark Proctor


Deserializing the Package objects from storage to memory consumes large amount of memory.  My tests showed that for a serialized size of 1MB, 18MB of memory would be consumed during deserialization, mostly from the method org.drools.rule.Package.readExternal.  A test program with resulting profile data would be uploaded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:46:01 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 16 Aug 2007 15:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1095) Deserializing
 Package Objects Consumes Large Amount of Memory
In-Reply-To: <17599698.1187293445172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28208799.1187293561298.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ming Jin updated JBRULES-1095:
------------------------------

    Attachment: testdrools.zip

> Deserializing Package Objects Consumes Large Amount of Memory
> -------------------------------------------------------------
>
>                 Key: JBRULES-1095
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1095
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>         Attachments: testdrools.zip
>
>
> Deserializing the Package objects from storage to memory consumes large amount of memory.  My tests showed that for a serialized size of 1MB, 18MB of memory would be consumed during deserialization, mostly from the method org.drools.rule.Package.readExternal.  A test program with resulting profile data would be uploaded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:46:01 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Thu, 16 Aug 2007 15:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1085) Rule fires
 before calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1850288.1187293561529.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1085?page=comments#action_12372620 ] 
            
Markus Reitz commented on JBRULES-1085:
---------------------------------------

I have a self-contained test which demonstrates the problem in 4.0GA. Do I have to reopen the issue to be able to attach the file?

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:52:01 2007
From: jira-events at lists.jboss.org (Andy Pemberton (JIRA))
Date: Thu, 16 Aug 2007 15:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24812147.1187293921685.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372628 ] 
            
Andy Pemberton commented on JBPORTAL-1631:
------------------------------------------

Well, I still feel that this solution is over-architecting the problem but it will certainly solve the business need. I still hold that implementing this feature as you've described it into JBoss Portal will detract from its standards compliance. 

a) Agreed - this is not a security issue but does point out that using the user-agent string to target CSS may not be effective. Conditional comments do not rely on this HTTP header, so it would be harder to "lie" to them.

Anyway, it will be important to ensure that the solution will allow for feeding multiple style sheets to the various user agents. In other words, providing only one if/otherwise set would be a problem. Whereas, multiple if/otherwise blocks would allow a developer to feed a stylesheet  to all browsers, and then a 'corrective' style sheet to versions of IE.

Ah, by the way - that's a cool feature of conditional comments. If IE8 decided to stop supporting them, they would just appear as regular HTML comments. Whereas your solution will require additional processing for EVERY user agent that hits the portal site, conditional comments only make extra work occur for the bad-boy-browser - all other browsers see a comment. 

... and, no takers here on implementing the cross-platform CSS compiler. = ] 

> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:54:03 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 15:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1096) NPE when using
 "exists" with "from"
Message-ID: <994629.1187294043149.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE when using "exists" with "from"
-----------------------------------

                 Key: JBRULES-1096
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1096
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder, Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


NPE when adding a package with the following rule to a rulebase:

package org.drools;

global java.util.List results;

rule "exists with from"
	when
		Cheesery( $cheeses : cheeses ) 
		exists( Cheese( type == "stilton" ) from $cheeses )
	then
		results.add( "true" );
end


java.lang.NullPointerException
	at org.drools.reteoo.builder.BuildUtils.createBetaNodeConstraint(BuildUtils.java:168)
	at org.drools.reteoo.builder.GroupElementBuilder$ExistsBuilder.build(GroupElementBuilder.java:306)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:136)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:109)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:262)
	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:337)
	at org.drools.integrationtests.FirstOrderLogicTest.testExistsWithFrom(FirstOrderLogicTest.java:717)
	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 junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:56:01 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Thu, 16 Aug 2007 15:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21242988.1187294161166.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372629 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

A clean unit test that just shows ONE of the problems seems useful.  
I think it's going to be really hard to come up with fixes that work in all contexts, so the more to check against, the better chance the fix will "stick".
So I definitely wouldn't close it, especially after Jeff Johnson found it reproducible.

This appears to be fallout from the recursive execution model, which I've whined about at some length already on the forum as an accident waiting to happen.  I've done some work to unwind the recursion, but don't have time to do full regression-testing.  Here's the essence of it.  I'm sure I've made some naive assumptions, and changes between 3.2 and 3.2.1 may require some adjustments. 

In Node.java, the execute method looks like this (based on 3.2 GA).  Note comments in caps.

=======

  public void execute(ExecutionContext executionContext) {
    // if there is a custom action associated with this node
    if (action!=null) {
      executionContext.setExecutingNode(true);    // RAISE FLAG IN CONTEXT TO SAY WE"RE IN ACTIONHANDLER
      try {
        // execute the action
        action.execute(executionContext);
        executionContext.setExecutingNode(false);  // LOWER FLAG IN CONTEXT

        // CHECK FOR POSTPONED TRANSACTION AND EXECUTE IT NOW
        Transition pendingTransition = executionContext.getPendingTransition();
        if ( pendingTransition != null )
        {
            executionContext.setPendingTransition(null);
            leave(executionContext, pendingTransition);
        }

      } catch (Exception exception) {
        executionContext.setExecutingNode(false);
        executionContext.setPendingTransition(null);
        // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
        // search for an exception handler or throw to the client
        raiseException(exception, executionContext);
      }

    } else {
      // let this node handle the token
      // the default behaviour is to leave the node over the default transition.
      leave(executionContext);
    }
  }

======
The ExecutionContext fields 
  protected Transition pendingTransition = null;
  protected boolean executingNode = false;
have straightforward accessors.  

=========
Node.leave() now starts out:

  public void leave(ExecutionContext executionContext, Transition transition) {

    if (transition==null) throw new JbpmException("can't leave node '"+this+"' without leaving transition");

    // IF WE ARE IN THE MIDDLE OF AN ACTIONHANDLER, WAIT TILL WE'VE FINISHED.
    if ( executionContext.isExecutingNode() )
    {
      assert(executionContext.getPendingTransition() == null);
      executionContext.setPendingTransition(transition);
      return;
    }
 

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:10:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 16 Aug 2007 16:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30346174.1187295001322.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372632 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

I agree it is a nice and a well written unit test (nice change from comments by some others ;-) ) and a analysis (nice addition by you btw) but isn't this test identical to what is in the jobExecutorDbTest? Or do I mis something?



> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:26:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 16:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1096) NPE when using
 "exists" with "from"
In-Reply-To: <994629.1187294043149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22319853.1187295961241.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1096.
----------------------------------

    Resolution: Done

Fixed and added integration tests. This is a regression introduced when we refactored patterns to have a source field.

> NPE when using "exists" with "from"
> -----------------------------------
>
>                 Key: JBRULES-1096
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1096
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> NPE when adding a package with the following rule to a rulebase:
> package org.drools;
> global java.util.List results;
> rule "exists with from"
> 	when
> 		Cheesery( $cheeses : cheeses ) 
> 		exists( Cheese( type == "stilton" ) from $cheeses )
> 	then
> 		results.add( "true" );
> end
> java.lang.NullPointerException
> 	at org.drools.reteoo.builder.BuildUtils.createBetaNodeConstraint(BuildUtils.java:168)
> 	at org.drools.reteoo.builder.GroupElementBuilder$ExistsBuilder.build(GroupElementBuilder.java:306)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:136)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:109)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:262)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:337)
> 	at org.drools.integrationtests.FirstOrderLogicTest.testExistsWithFrom(FirstOrderLogicTest.java:717)
> 	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 junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:30:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 16 Aug 2007 16:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31172573.1187296201338.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1056.
---------------------------------

    Resolution: Done

fixed :)

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: TestDrools.java, testdrools.zip, TestObject.java
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Thu Aug 16 16:35:13 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 16 Aug 2007 16:35:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1041) jBPM documentation
 changes to include Deployment and Debug steps.
In-Reply-To: <21593965.1187275262652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23444661.1187296513678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1041?page=all ]

Ronald van Kuijk closed JBPM-1041.
----------------------------------

    Resolution: Incomplete Description

> jBPM documentation changes to include Deployment and Debug steps.
> -----------------------------------------------------------------
>
>                 Key: JBPM-1041
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1041
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Documentation
>    Affects Versions: jBPM GPD 3.0.7
>         Environment: All
>            Reporter: Satya Satyamoorthy
>         Assigned To: Tom Baeyens
>             Fix For: jBPM GPD 3.0.7
>
>
> Please add adequate documentation listing the steps to 
> 1. Deploy the processes to different environments - such as test, user acceptance, production etc. from the RHDS.
> 2. Set breakpoints and Trace and 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 lists.jboss.org  Thu Aug 16 16:39:01 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Thu, 16 Aug 2007 16:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19041553.1187296741215.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372645 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

Ronald,  
I can't take the time to read them closely enough to respond accurately.
They certainly are close, but close doesn't count.
Does JobExecutorDbTest fail in the same way?
I don't see any reference to it in any JIRA reports, so if it is failing, I'd reference it on this report, rather than close the report.
-Ed


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:51:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 16 Aug 2007 16:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-449) maven-jbossaop-plugin
 cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13827960.1187297461824.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Anders Andersen closed JBAOP-449.
---------------------------------


I have testet the change
and now no aoppath will generate a default with correct file path.


> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Thu Aug 16 17:02:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 16 Aug 2007 17:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7960769.1187298121436.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anders Andersen reopened JBAOP-453:
-----------------------------------

             
I have testet this changes as well.
I have moved all AOP dependencies away and it works !!!!!!!
VERY BEAUTIFUL!!!!

But it did not work for me, because the compiler classpath needs to know the dependency list as well.

When I add code
      for(Object one : project.getDependencyArtifacts()) {
         Artifact a=(Artifact)one;
          sb.append(a.getFile().toString()).append(File.pathSeparator);
      }
to the createClassPathList() it works for me.
I do understand that AOPC must know the dependent artifacts, because it can get factories, classes, log-classes or what ever the AOP uses from here.

   private String createClassPathList()
   {
      StringBuffer sb = new StringBuffer();
      for(Artifact a : pluginArtifacts)
      {
         sb.append(a.getFile().toString()).append(File.pathSeparator);
      }
      for(Object one : project.getDependencyArtifacts()) {
         Artifact a=(Artifact)one;
          sb.append(a.getFile().toString()).append(File.pathSeparator);
      }

      if(isTest())
         sb.append(project.getBuild().getTestOutputDirectory());
      else
         sb.append(project.getBuild().getOutputDirectory());

      return sb.toString();
   }


> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug 16 17:08:11 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 17:08:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2443385.1187298491179.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372657 ] 
            
Thomas Heute commented on JBPORTAL-1631:
----------------------------------------

Note that this solution doesn't aim at only solving the CSS compatibility issues but the different kind of browsers.

a) It's actually very easy to have a wrong behavior, try to install IE 5 and IE 6 on a same machine, both will be seen as the latest version you install (i guess it takes it from the windows registry) and the conditonal statement will be fooled. The idea of changing the user-agent is usally to fool the server to avoid some display problem. let's say you get a new for of Netscape called MyGreatBrowser, and the server is trying to send a IE CSS because it doesn't know about this new browser, then the client still has a way to "force" the Netscape stylesheet, it's a feature.

The code-like stuff i was talking about should be for all the different themes (actually it should also have a way to define no CSS for some themes on some browsers (maybe you will only have 2 themes for the Opera on the Nintendo Wii, but 10 for traditional browsers)

My example about IE8 was to say that if IE8 stop supporting this or do it in another way, you would end up with the same problem as of today, you couldn't define a special CSS for IE8.

The additional processing is really cheap, 1 parsing per session is something we can offer. (We can also argue that the other browsers also have to parse this conditional statement to ignore it).

Anyway, i am not against supporting the conditional statement, but i didn't see a little change that would make it work (i didn't look very hard). So if we need to do extra work, let's do it the good way, even more since we are re-designing the whole theme/layout support for next major versions.

Too bad for the CSS compiler :) JBoss CSS Compiler sounded like a good project name :-D 

Thanks for your input, don't think i'm just against the idea, i'm trying to get the best from the original idea. I totally agree that not supporting this is a major problem for IE versions. (more than any other browser)

> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 17:10:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 17:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31791695.1187298601162.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372658 ] 
            
Jeff Johnson commented on JBPM-1042:
------------------------------------

I used jobExecutorDbTest as the starting point to the test case.  I plagarized heavily. 
The changes are:
1. Only creates one process instances.  Eliminates the issues associated with multiple job executor threads running.  You can change nbrOfThreads to 1 and still get the same behavior. I don't this this failure has anything to do with mulitiple job executor threads or hibernate session issues.
2. The process definition is simpler. It only contains a start node, node1, node2, and end  node.

My biased, novice opinion FWIW: Leave it open. It is slightly different test case, perhaps simpler case. Based on my review of the discussions and the JIRA reports, I think there are multiple issues that interact with each other. I tried to create a test case that isolates one specific problem. With luck solving this problem might make some of the other things more deterministic and simpler to debug. 

Looks like Node.execute(ExecutionContext context) change noticeable from 3.2GA (which I haven't used)
Just a little more detail.
In 3.2.1 Node.execute() calls org.jbpm.graph.def.GraphElement.executeAction().  This is the code that locks the token and then actually makes the call to action.execute().  Notice that the lock isn't unlocked until the finally block.  
// GraphElement
public void executeAction(Action action, ExecutionContext executionContext) {
    Token token = executionContext.getToken();

    // create action log
    ActionLog actionLog = new ActionLog(action);
    token.startCompositeLog(actionLog);

    try {
      // update the execution context
      executionContext.setAction(action);

      // execute the action
      log.debug("executing action '"+action+"'");
      String lockOwnerId = "token["+token.getId()+"]"; 
      try {
        token.lock(lockOwnerId);   // THIS IS WERE IT GETS LOCKED
        
        if (UserCodeInterceptorConfig.userCodeInterceptor!=null) {
          UserCodeInterceptorConfig.userCodeInterceptor.executeAction(action, executionContext);
        } else {
          action.execute(executionContext);
        }

      } finally {
        token.unlock(lockOwnerId);
      }
   
    } catch (Exception exception) {
      // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
      log.error("action threw exception: "+exception.getMessage(), exception);
      
      // log the action exception 
      actionLog.setException(exception);
   
      // if an exception handler is available
      raiseException(exception, executionContext);
      
    } finally {
      executionContext.setAction(null);
      token.endCompositeLog();
    }
  }

The problem comes in Node.enter() in the fragment below.  

   // execute the node
    if (isAsync) {
      ExecuteNodeJob job = createAsyncContinuationJob(token);
      MessageService messageService = (MessageService) 
             Services.getCurrentService(Services.SERVICENAME_MESSAGE);
      messageService.send(job);
      token.lock(job.toString());    //####  OOPS! THE TOKEN IS ALREADY LOCKED! #####
    } else {
      execute(executionContext);
    }
 

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 17:29:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 16 Aug 2007 17:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
Message-ID: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>

NodeNotExistException with concurent put/remove operations
----------------------------------------------------------

                 Key: JBCACHE-1164
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
    Affects Versions: 1.4.1.SP4
         Environment: Windows XP, Sun jdk150_06 
            Reporter: Jacek Halat
         Assigned To: Jason T. Greene


When 2 Threads are putting/removing data from this same node, put operation fails with exception

org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
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:89) 
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) 
(...) 

Thread 1 is calling: 
	cache.remove("/a/b/c/d");
	cache.remove("/a");
 Thread 2 is calling: 
	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Thu Aug 16 17:31:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 16 Aug 2007 17:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
In-Reply-To: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5197496.1187299861186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1164?page=all ]

Jacek Halat updated JBCACHE-1164:
---------------------------------

    Attachment: ConcurentOperationsTest.java

TestCase ilustrating this bug.

> NodeNotExistException with concurent put/remove operations
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1164
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: ConcurentOperationsTest.java
>
>
> When 2 Threads are putting/removing data from this same node, put operation fails with exception
> org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
> 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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
> 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:89) 
> 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) 
> (...) 
> Thread 1 is calling: 
> 	cache.remove("/a/b/c/d");
> 	cache.remove("/a");
>  Thread 2 is calling: 
> 	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Thu Aug 16 17:31:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 16 Aug 2007 17:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15145990.1187299861500.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372674 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Pleaze fix the dependency resolution by adding compile

* @requiresDependencyResolution compile 

otherwise we cannot scope dependencies to i.e. provided

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug 16 17:51:03 2007
From: jira-events at lists.jboss.org (Chris Rose (JIRA))
Date: Thu, 16 Aug 2007 17:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-69) Hibernate MBean
 not releasing
 connections per-statement despite default configuration
Message-ID: <500430.1187301063369.JavaMail.jira@cloud.prod.atl2.jboss.com>

Hibernate MBean not releasing connections per-statement despite default configuration
-------------------------------------------------------------------------------------

                 Key: HIBERNATE-69
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-69
             Project: Hibernate
          Issue Type: Bug
         Environment: JBoss AS 4.0.4 GA
Linux (Fedora core 5)
Oracle 9i
            Reporter: Chris Rose
         Assigned To: Steve Ebersole


When flushing the hibernate connection on a managed hibernate module (har file) I get the following warning:
15:32:23,879 INFO  [CachedConnectionManager] Closing a connection for you.  Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection at 16c5525
java.lang.Throwable: STACKTRACE

The stack trace (found below) indicates that this is occurring in the session.flush method which I call in order to read in my database's generated columns:
session.save(newObject);
session.flush ();
session.refresh (newObject);

This is in a session bean method with the transaction-type: required

The stack trace has another error after it that I am not sure is related to the initial problem, but might be; I attach it for completeness, if nothing else.

Stacktrace follows:
15:32:23,879 INFO  [CachedConnectionManager] Closing a connection for you.  Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection at 16c5525
java.lang.Throwable: STACKTRACE
	at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:290)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:400)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:812)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
	at org.hibernate.connection.DatasourceConnectionProvider.getConnection(DatasourceConnectionProvider.java:69)
	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:417)
	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
	at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:94)
	at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
	at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:218)
	at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2106)
	at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2503)
	at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51)
	at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:993)
	at com.aciworldwide.ecourier.management.ejb.OperationsManagerSessionBean.updateUser(OperationsManagerSessionBean.java:1323)
	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.invocation.Invocation.performCall(Invocation.java:359)
	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
	at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:64)
	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:350)
	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.SessionContainer.internalInvoke(SessionContainer.java:648)
	at org.jboss.ejb.Container.invoke(Container.java:954)
	at sun.reflect.GeneratedMethodAccessor190.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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
	at sun.reflect.GeneratedMethodAccessor189.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:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)
15:32:23,923 INFO  [ConnectionManager] forcing batcher resource cleanup on transaction completion; forgot to close ScrollableResults/Iterator?
15:32:23,923 WARN  [AbstractBatcher] Could not close a JDBC result set
java.sql.SQLException: Already closed
	at org.jboss.resource.adapter.jdbc.WrappedResultSet.close(WrappedResultSet.java:178)
	at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:310)
	at org.hibernate.jdbc.ConnectionManager.afterTransaction(ConnectionManager.java:291)
	at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:214)
	at org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85)
	at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1526)
	at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1198)
	at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:413)
	at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:493)
	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361)
	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.SessionContainer.internalInvoke(SessionContainer.java:648)
	at org.jboss.ejb.Container.invoke(Container.java:954)
	at sun.reflect.GeneratedMethodAccessor190.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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
	at sun.reflect.GeneratedMethodAccessor189.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:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)

jboss-service.xml for the har file:
<?xml version="1.0" encoding="UTF-8"?>
<mbean code="org.jboss.hibernate.jmx.Hibernate" name="jboss.har:service=ecdb-cralphaiss-Hibernate">
  <attribute name="DatasourceName">java:ecourier-cralphaissDS</attribute>
  <attribute name="SessionFactoryName">java:ecourier-ecdb-cralphaiss-SessionFactory</attribute>
  <attribute name="Dialect">org.hibernate.dialect.Oracle9Dialect</attribute>
  <attribute name="CacheProviderClass">org.hibernate.cache.HashtableCacheProvider</attribute>
  <attribute name="ScanForMappingsEnabled">false</attribute>
  <attribute name="ShowSqlEnabled">true</attribute>
</mbean>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 18:07:01 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Aug 2007 18:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32198226.1187302021082.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Richard Achmatowicz closed JBAS-4422.
-------------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                   JBossAS-4.2.2.GA
       Resolution: Done
         Assignee: Richard Achmatowicz  (was: Stan Silvert)

Tested the change on RHEL 5 and Windows. 
Committed the change to 
svn.jboss.org:/repos/jbossas/branches/JBPAPP_4_2_0_GA_CP 
svn.jboss.org:/repos/jbossas/branches/Branch_4_2 
svn.jboss.org:/repos/jbossas/trunk


> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Richard Achmatowicz
>            Priority: Trivial
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Thu Aug 16 18:11:20 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 18:11:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1627) Problem
 destroying service
 portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
In-Reply-To: <12607797.1186753680992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13573574.1187302280164.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1627.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

Thanks a lot Roman for this patch !

> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> ------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1627
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1627
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: JBPORTAL-1627.patch
>
>
> On AS shutdown:
> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> java.lang.reflect.UndeclaredThrowableException
>         at $Proxy0.destroy(Unknown Source)
>         at org.jboss.system.ServiceController.destroy(ServiceController.java:577)
>         at org.jboss.system.ServiceController.shutdown(ServiceController.java:714)
>         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.server.ServerImpl$ShutdownHook.shutdownServices(ServerImpl.java:1079)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1037)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
> Caused by: javax.management.InstanceNotFoundException: portal:service=ContentRenderer,type=GoogleWidgetPortletInstance is not registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:653)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
>         ... 15 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 lists.jboss.org  Thu Aug 16 18:38:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 18:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-1608) CMS content type
 always display with no decoration
In-Reply-To: <3650382.1185258947112.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2170054.1187303881078.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute closed JBPORTAL-1608.
----------------------------------


> CMS content type always display with no decoration
> --------------------------------------------------
>
>                 Key: JBPORTAL-1608
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1608
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Changing window properties has no 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 lists.jboss.org  Thu Aug 16 18:51:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 16 Aug 2007 18:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32939928.1187304661192.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372685 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

i added the dependency resolution, but i dont understand why we need to append project dependant artifacts to the classpath. if you use the plugin and want to add dependencies to it you can just add them in the plugin configuration and they will be added from there. see paul's comment at 9 aug. - or am i missing something?

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug 16 20:17:01 2007
From: jira-events at lists.jboss.org (Jeff DeLong (JIRA))
Date: Thu, 16 Aug 2007 20:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1097) Manual
 html_single does not have TOC entry for Chapter 9 BRMS
Message-ID: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>

Manual html_single does not have TOC entry for Chapter 9 BRMS
-------------------------------------------------------------

                 Key: JBRULES-1097
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.GA
            Reporter: Jeff DeLong
         Assigned To: Mark Proctor
             Fix For: 4.0.1


Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 20:19:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 20:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1097) Manual
 html_single does not have TOC entry for Chapter 9 BRMS
In-Reply-To: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6269503.1187309941187.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1097:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Manual html_single does not have TOC entry for Chapter 9 BRMS
> -------------------------------------------------------------
>
>                 Key: JBRULES-1097
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Jeff DeLong
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 22:51:01 2007
From: jira-events at lists.jboss.org (Andy Pemberton (JIRA))
Date: Thu, 16 Aug 2007 22:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4438335.1187319061257.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372694 ] 
            
Andy Pemberton commented on JBPORTAL-1631:
------------------------------------------

Sounds good; thanks for the quick feed back. Your solution would definitely solve the issue our client is having and I look forward to using JBoss Portal 2.8.

> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 03:34:17 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 03:34:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1165) Endless loop in
 PessimisticLockInterceptor
Message-ID: <14669904.1187336057521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Endless loop in PessimisticLockInterceptor
------------------------------------------

                 Key: JBCACHE-1165
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.1.SP4
         Environment: Windows XP, Sun jdk150_06 
Solaris 10
            Reporter: Jacek Halat
         Assigned To: Manik Surtani


When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop.
Main loop looks like:
				for (int x = 0; x < 1000; x++) {
					tm.begin();
					System.out.println("R" + Thread.currentThread().getName());
					//inside transaction
					cache.remove("/a");
					System.out.println("AR" + Thread.currentThread().getName());
					tm.commit();
					//outside transaction
					System.out.println("P" + Thread.currentThread().getName());
					cache.put("/a/b/c/d", "text"+x,"b");
					System.out.println("AP" + Thread.currentThread().getName());
				}



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 03:38:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 03:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1165) Endless loop in
 PessimisticLockInterceptor
In-Reply-To: <14669904.1187336057521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19001128.1187336281161.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1165?page=all ]

Jacek Halat updated JBCACHE-1165:
---------------------------------

    Attachment: ConcurentPutRemoveTest.java
                ConsoleOut.log

JUnit test to this issue.
This test sometimes finish with success, sometimes fails with NodeNotExistException and sometimes goes into infinitive loop.

Attached ConsoleOutput with ThreadDumps when test goes into infinivie loop.

> Endless loop in PessimisticLockInterceptor
> ------------------------------------------
>
>                 Key: JBCACHE-1165
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>         Attachments: ConcurentPutRemoveTest.java, ConsoleOut.log
>
>
> When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop.
> Main loop looks like:
> 				for (int x = 0; x < 1000; x++) {
> 					tm.begin();
> 					System.out.println("R" + Thread.currentThread().getName());
> 					//inside transaction
> 					cache.remove("/a");
> 					System.out.println("AR" + Thread.currentThread().getName());
> 					tm.commit();
> 					//outside transaction
> 					System.out.println("P" + Thread.currentThread().getName());
> 					cache.put("/a/b/c/d", "text"+x,"b");
> 					System.out.println("AP" + Thread.currentThread().getName());
> 				}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 04:14:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 04:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
Message-ID: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>

UpgradeException on concurent put/remove operation
--------------------------------------------------

                 Key: JBCACHE-1166
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
         Environment: Windows XP, Sun jdk150_06 
            Reporter: Jacek Halat
         Assigned To: Manik Surtani
         Attachments: ConcurentOperationTest.java

When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock

Full StackTrace:
org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
	... 5 more
Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
	... 25 more
Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
	... 27 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 lists.jboss.org  Fri Aug 17 04:14:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 04:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29018335.1187338441752.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=all ]

Jacek Halat updated JBCACHE-1166:
---------------------------------

    Attachment: ConcurentOperationTest.java

JUnit test to this issue

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>         Attachments: ConcurentOperationTest.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Fri Aug 17 04:31:01 2007
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Fri, 17 Aug 2007 04:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7131093.1187339461189.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Tom Baeyens updated JBPM-1042:
------------------------------

    Attachment: jbpm-jpdl.jar

can you guys check out the attached patched jbpm-jpdl.jar file.  does that resolve this problem for you ?

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 04:49:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 04:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1041) jBPM documentation
 changes to include Deployment and Debug steps.
In-Reply-To: <21593965.1187275262652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27092563.1187340541231.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1041?page=comments#action_12372717 ] 
            
Ronald van Kuijk commented on JBPM-1041:
----------------------------------------

hmmm I was sure I also added a comment... here we go

- old version of GPD, very old version
- GPD has it's own project in jira, called GPD: http://jira.jboss.com/jira/browse/GPD
- very little info
- different requests in one issue

Now more constructive answers

1: totally up to you. use the console, create/use ant tasks, create you own app... pick one...if you want different deployment methods between test and production, then do so.. if not, keep them the same.

2: Runtime at the 'process' level? e.g. when a certain task is encountered? then file a jira issue for the GPD. This is *not* just a documentation  issue but a very complex thing to build. You can do this in unit tests very easily btw...

> jBPM documentation changes to include Deployment and Debug steps.
> -----------------------------------------------------------------
>
>                 Key: JBPM-1041
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1041
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Documentation
>    Affects Versions: jBPM GPD 3.0.7
>         Environment: All
>            Reporter: Satya Satyamoorthy
>         Assigned To: Tom Baeyens
>             Fix For: jBPM GPD 3.0.7
>
>
> Please add adequate documentation listing the steps to 
> 1. Deploy the processes to different environments - such as test, user acceptance, production etc. from the RHDS.
> 2. Set breakpoints and Trace and 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 lists.jboss.org  Fri Aug 17 05:32:01 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Fri, 17 Aug 2007 05:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-150) In-place label edit
 box offset in scrolled editor
Message-ID: <33534539.1187343121259.JavaMail.jira@cloud.prod.atl2.jboss.com>

In-place label edit box offset in scrolled editor
-------------------------------------------------

                 Key: GPD-150
                 URL: http://jira.jboss.com/jira/browse/GPD-150
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
            Reporter: David Good
         Assigned To: Koen Aers
            Priority: Minor


When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position (see attachment)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:37:01 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Fri, 17 Aug 2007 05:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-150) In-place label edit
 box offset in scrolled editor
In-Reply-To: <33534539.1187343121259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25441816.1187343421363.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-150?page=all ]

David Good updated GPD-150:
---------------------------

    Attachment: screenshot-1.jpg

> In-place label edit box offset in scrolled editor
> -------------------------------------------------
>
>                 Key: GPD-150
>                 URL: http://jira.jboss.com/jira/browse/GPD-150
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
>            Reporter: David Good
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: screenshot-1.jpg
>
>
> When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position (see attachment)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:37:01 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Fri, 17 Aug 2007 05:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-150) In-place label edit
 box offset in scrolled editor
In-Reply-To: <33534539.1187343121259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30117942.1187343421677.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-150?page=all ]

David Good updated GPD-150:
---------------------------

    Description: When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position if the scroll bars are not in the origin. (see attachment)  (was: When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position (see attachment))

> In-place label edit box offset in scrolled editor
> -------------------------------------------------
>
>                 Key: GPD-150
>                 URL: http://jira.jboss.com/jira/browse/GPD-150
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
>            Reporter: David Good
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: screenshot-1.jpg
>
>
> When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position if the scroll bars are not in the origin. (see attachment)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:51:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 05:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-983) concurrent process
 execution fails
In-Reply-To: <30055235.1181555411656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20311897.1187344262314.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-983?page=comments#action_12372722 ] 
            
Ronald van Kuijk commented on JBPM-983:
---------------------------------------

the issue in JBPM-1042 is one of the errors I encountered during testing the above cases.  So look there for some more info

> concurrent process execution fails
> ----------------------------------
>
>                 Key: JBPM-983
>                 URL: http://jira.jboss.com/jira/browse/JBPM-983
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: Hypersonic in-memory database, JobExecutor configured with 5 threads
>            Reporter: Alexander Schlett
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM 3.3
>
>         Attachments: SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java
>
>
> concurrent execution of async nodes with multiple JobExecutor threads fails. the effect is:
> 1) job sync within JobExecutor fails due to org.hibernate.StaleObjectStateException
> 2) process gets stuck in join node and never ends
> junit test for this is attached, it's a simple process with just a fork and a join and some scripts inbetween.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:51:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 05:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1744744.1187344262762.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372723 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

Ed, 

You are correct in pointing me to your limited amount of time. I already respect you a lot for the time you *do* invest. 

You are also correct in pointing out that this error is not mentioned in one of the other issues. It did occur there when I was investigating. Mea culpa. 

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 07:53:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 17 Aug 2007 07:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-454) Upgrade jboss retro
	to 1.1.2
Message-ID: <31251926.1187351581112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss retro to 1.1.2
----------------------------

                 Key: JBAOP-454
                 URL: http://jira.jboss.com/jira/browse/JBAOP-454
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Flavia Rainone
             Fix For: 2.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 lists.jboss.org  Fri Aug 17 08:11:08 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:11:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1633) Build new
	identity portlets
Message-ID: <20557023.1187352668315.JavaMail.jira@cloud.prod.atl2.jboss.com>

Build new identity portlets
---------------------------

                 Key: JBPORTAL-1633
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1633
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


Building new identity portlets.

1 for users
1 for managing users and 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 lists.jboss.org  Fri Aug 17 08:11:08 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:11:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1634) Finish the user
 email
 verification after registration and when a user change his email
Message-ID: <21470014.1187352668490.JavaMail.jira@cloud.prod.atl2.jboss.com>

Finish the user email verification after registration and when a user change his email 
---------------------------------------------------------------------------------------

                 Key: JBPORTAL-1634
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1634
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:11:08 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:11:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1635) Lost password
 feature, attribute a random password and send it by email
Message-ID: <26661164.1187352668657.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lost password feature, attribute a random password and send it by email 
------------------------------------------------------------------------

                 Key: JBPORTAL-1635
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1635
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:13:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1636) Captcha support
 (with jcpatcha probably)
Message-ID: <32032096.1187352781527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Captcha support (with jcpatcha probably) 
-----------------------------------------

                 Key: JBPORTAL-1636
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1636
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:13:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1637) XML
 configuration of user properties
Message-ID: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>

XML configuration of user properties
------------------------------------

                 Key: JBPORTAL-1637
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


 parsed with 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 lists.jboss.org  Fri Aug 17 08:13:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1638) Modify "edit
 profile" to let modification of email and password
Message-ID: <8183870.1187352782096.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify "edit profile" to let modification of email and password 
----------------------------------------------------------------

                 Key: JBPORTAL-1638
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1638
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:15:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1639) Let the
 administrator enable or disable a user
Message-ID: <17294032.1187352901536.JavaMail.jira@cloud.prod.atl2.jboss.com>

Let the administrator enable or disable a user 
-----------------------------------------------

                 Key: JBPORTAL-1639
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1639
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:38:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 08:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10356527.1187354281562.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372733 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

Actually its already parsed. You can obtain list of user properties from the profile

UserProfileModule.getProfileInfo.getPropertiesInfo()

returns a Map o PropertyInfo objects that describe configured user properties. So you only need to render proper view based on that info

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:40:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 08:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17183608.1187354401580.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372734 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

also you should check PropertyInfo.getAccessMode() to check for read-only props.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:44:10 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27746881.1187354650634.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372738 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

There is a need for other metadata like:
mandatory or not...
input text, checkbox ? If we want to build the JSF page dynamically (not at first, not sure we will even do it)

I actually wondered what the identity XML is all about in the current case.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:48:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8992485.1187354881498.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372739 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

"Mandatory" and "type" are already there :)

Nice.

Why is it used today ? Does the user portlet check this ?

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:50:06 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:50:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <38752.1187355006155.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372741 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

Yes everything is there, and what's missing could be added, we would need stuff like:

Should appear at registration
Should appear in the user profile

Somehow i thought it was only used for database.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:54:03 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 08:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31887036.1187355243363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372743 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

most of them are not used right now (it was actually added having dynamic jsp page creation in mind ;)). I have also other ones on plate for 2.8 related to profile
http://jira.jboss.com/jira/browse/JBPORTAL-1493
http://jira.jboss.com/jira/browse/JBPORTAL-1494

I'm open for all the suggestions as I don't know all the use cases from UI point of view.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 09:05:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11509192.1187355901354.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372744 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

Ok then we will just add another config-file in core-identity for pure UI stuff like the one i mentionned and map on the property name.

Thanks a lot for your comments !

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 10:30:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 17 Aug 2007 10:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1047) class Cast
 Exception when using OR (||)
In-Reply-To: <20755281.1185814069735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20447200.1187361001258.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1047?page=comments#action_12372753 ] 
            
Edson Tirelli commented on JBRULES-1047:
----------------------------------------

I added parser tests, but parsing is being correctly handled.

Can you please show us any rules you have in the same rule base that are using an "eval()" statement that does any check on a Relation object?

The problem may happen because of this rule, but is being triggered by a rule that contains an eval().

Thanks.

> class Cast Exception when using OR (||)
> ---------------------------------------
>
>                 Key: JBRULES-1047
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1047
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows, X86
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> When I define a rule:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct, 
>                active:active==$1,
>                relationName=="Old")
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ..The bove works. 
> BUT, when I do the following:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> || Relation( contact==cntct, 
>                active:active==$1,
>                relationName==null)
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ... The script compiles anda stateless Session is created successfully, 
> but at 
> runtime/execution it fails with the exception:
> java.lang.ClassCastException: com.arjun.brms.businessObjects.Contact
> org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:75)
> org.drools.reteoo.EvalConditionNode.assertTuple (EvalConditionNode.java:141)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple 
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:317)
> org.drools.reteoo.AlphaNode.assertObject (AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject 
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> org.drools.reteoo.Rete.assertObject(Rete.java:168)
> org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java :190)
> org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java :822)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> Class diagram:
> ~~~~~~~~~~~~~~~~
> Contact<-- bi-directional association -->List<Relation>
> =============================================================================
> Edson comments (Response) :
> -----------------------------------------
> It is a bug since a more friendly message should be raised at compile time stating that your "contact" declaration is not available in one of your logical branches. 
>     Having said that, what you want to do is make your OR take priority over the implicit AND and as such, you need to add () around the OR: 
> When
> contact:Contact (initialized==true)
> exr: ( Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> or Relation( contact==cntct,
>                active:active==$1, 
>                relationName==null) )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    Having said that, better yet for you would not to use the OR CE, but to use restriction connectives. This would be the most efficient (and clean) way of writing your rule: 
> When
> contact:Contact (initialized==true)
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName =="Old" || == null )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    As a syntax sugar, you could also write:
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName in ( "Old", null ) )
>    Can you please open a JIRA with your test case for the bug? 
>    Thank you,
>         Edson
> -------------------
> Note: The above suggestion worked, no runtime errors with 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 lists.jboss.org  Fri Aug 17 10:38:30 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 17 Aug 2007 10:38:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-397) Add better error
 handling to
 retro when an attempt is made to retro the same class twice.
Message-ID: <26091371.1187361510411.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add better error handling to retro when an attempt is made to retro the same class twice.
-----------------------------------------------------------------------------------------

                 Key: JBBUILD-397
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-397
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.2.GA


If the same class is weaved twice, jboss-retro gives an error that the class is frozen and pruned.  Retro should check at the beginning of the process to see if there are any classes that will be weaved twice, and then give an error describing that one of them should 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 lists.jboss.org  Fri Aug 17 10:38:30 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 17 Aug 2007 10:38:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-397) Add better error
 handling to
 retro when an attempt is made to retro the same class twice.
In-Reply-To: <26091371.1187361510411.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28424591.1187361510556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-397?page=all ]

Paul Gier updated JBBUILD-397:
------------------------------

     Original Estimate: 1 day
    Remaining Estimate: 1 day

> Add better error handling to retro when an attempt is made to retro the same class twice.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-397
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-397
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.1.2.GA
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> If the same class is weaved twice, jboss-retro gives an error that the class is frozen and pruned.  Retro should check at the beginning of the process to see if there are any classes that will be weaved twice, and then give an error describing that one of them should 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 lists.jboss.org  Fri Aug 17 10:48:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 10:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26507771.1187362081578.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372757 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

If you want to have separate config for UserPortlet I should probably move some of those options to your file because it'll be doubled. But when I think about it....
2 separate files with similar content - a list of properties but with different parameters... looks like a config nightmare to me :)
So to add remove a property you need to put that info into two files. Maybe it would be better to workout common list of meta-data describing user property and extend current property-info.xml. The nature of the API is that its easy to extend and difficult to remove :)

The question is: What does it buy us to have separate configuration for UserPortlet for stuff that can be gathered from existing metadata.

There will be changes in identity in 2.8 but for this part it should be rather evolution than revolution.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 11:25:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 11:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1592) Backslashes
 not escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8303953.1187364301690.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=comments#action_12372764 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1592:
-----------------------------------------------

At first sorry I was not responding on this. I was off for some time and working on other stuff. 

To be honest I'm little confused about whats working and whats not. Are we talking about what kind of filter and where? Like I posted in forums if I put <value><![CDATA[(&(cn={0})(member=uid=jduke\\\, Duke,ou=People,o=test,dc=portal,dc=example,dc=com))]]></value> in identity-config.xml it works. So I understand that 3 backslashes are proper solution for filter placed there. 

Now for roles resolution I also was able to have it working with ldif I posted in forums. ("member: uid=jduke\, Duke,ou=People,o=test,dc=portal,dc=example,dc=com"). So roles resolution works ok with "strange" user names.

I'm not sure I understand properly what you wrote. 

"The filter is constructed by the code, one would not directly add LastName, FirstName for a filter, or only that specific user would be found."

So are we talking about filter in identity-config.xml or something in code? Mine or yours? :) Sory but this thread is little to long and hard to follow. Could you provide a real testcase for this? Like a short ldif + identity-config.xml I could play with. I'm not sure we are talking about the same things.


> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Fri Aug 17 11:37:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 11:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29216831.1187365021638.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372766 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

The idea is to extend what you have not double anything (except the key for mapping purpose)

But adding metadata info about UI specific stuff doesn't really belong to the identity service. So it shouldn't be read (it should be ignored) by the identity service.

In one place you define your properties, with read-write, mandatory or not... And in the other place you define if it should appear, where, in what color (i made this up) and so on...



> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 11:48:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 11:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20274960.1187365681719.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372768 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

ok.... <should_property_name_blink_when_mouse_is_over> won't be the best tag to place in profile-config.xml indeed :) 

If you think that some of the current metadata should be rather placed in UI configuration, or you have something in mind that should be add to identity metadata let me know.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 12:32:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 17 Aug 2007 12:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4612) Non ignorable white
 space is ignored while read env-entries
Message-ID: <31277697.1187368321048.JavaMail.jira@cloud.prod.atl2.jboss.com>

Non ignorable white space is ignored while read env-entries
-----------------------------------------------------------

                 Key: JBAS-4612
                 URL: http://jira.jboss.com/jira/browse/JBAS-4612
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf
             Fix For:  JBossAS-5.0.0.Beta3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 12:42:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 17 Aug 2007 12:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4612) Non ignorable white
 space is ignored while read env-entries
In-Reply-To: <31277697.1187368321048.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15273757.1187368921440.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf resolved JBAS-4612.
---------------------------------

    Resolution: Done

> Non ignorable white space is ignored while read env-entries
> -----------------------------------------------------------
>
>                 Key: JBAS-4612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4612
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 12:42:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 17 Aug 2007 12:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4612) Non ignorable white
 space is ignored while reading env-entries
In-Reply-To: <31277697.1187368321048.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8502406.1187368922155.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf updated JBAS-4612:
--------------------------------

    Summary: Non ignorable white space is ignored while reading env-entries  (was: Non ignorable white space is ignored while read env-entries)

> Non ignorable white space is ignored while reading env-entries
> --------------------------------------------------------------
>
>                 Key: JBAS-4612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4612
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 14:27:01 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 17 Aug 2007 14:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
Message-ID: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>

runaway SLSB instance creation with ThreadLocalPool
---------------------------------------------------

                 Key: EJBTHREE-1031
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, AS 4.2.0 GA
            Reporter: William DeCoste
         Assigned To: William DeCoste


Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:16:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Fri, 17 Aug 2007 15:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8336866.1187378161715.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372797 ] 
            
Jeff Johnson commented on JBPM-1042:
------------------------------------

The unit test seems to work fine with the provided jar. I used the provided jar in a more complicated test involving multiple process instances with multiple async nodes and multiple job executor threads.  Everything I've done so far now works as expected.

Sorry for the novice question but how / when will this patch be made part of a release? Will there be a CVS tag that I can use to pull down 3.2.1 + this patch?  Or perhaps the modified sources can be provided until this gets in a release.   I just don't want build / deploy our system based on a jar for which I don't have source. (not to mention that I'm curious about the solution).

Thanks for all your help and the quick resolution!

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:51:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 15:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28597140.1187380261283.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372801 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

Solution came from http://jira.jboss.com/jira/browse/JBPM-995

Changeset checkins: http://fisheye.jboss.com/changelog/JBPM/jbpm.3/jpdl?cs=MAIN:tbaeyens:20070815123339 

But a little more was done... see http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl



> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:53:05 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 15:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10114856.1187380385196.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Ronald van Kuijk closed JBPM-1042.
----------------------------------

    Fix Version/s: jBPM jPDL 3.2.2
       Resolution: Done

Patches from JBPM-995 seem to solve this as wel. Reporter confirmed this, so closing

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:59:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 15:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-793) Lease should
 synchronize access to client map
Message-ID: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lease should synchronize access to client map
---------------------------------------------

                 Key: JBREM-793
                 URL: http://jira.jboss.com/jira/browse/JBREM-793
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.1.GA, 2.2.1.SP1, 2.2.0.SP4_CP02
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Fri Aug 17 16:11:01 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Fri, 17 Aug 2007 16:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28188350.1187381461198.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372809 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

Ronald,
Are you sure that's all Tom sent in the jar?  
I assumed he sent some work that was not yet checked in.
If it was checked in, I must misunderstand the problem, or I'm overlooking something in the checkins, because I don't see anything relevant to the specific problem.
-Ed


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 16:19:20 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 17 Aug 2007 16:19:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1032) inconsistent
 results for
 CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
Message-ID: <32360816.1187381960564.JavaMail.jira@cloud.prod.atl2.jboss.com>

inconsistent results for CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
-----------------------------------------------------------------------------------------

                 Key: EJBTHREE-1032
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1032
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1
            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 lists.jboss.org  Fri Aug 17 16:34:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 16:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12175378.1187382841103.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The changes to org.jboss.remoting.MicroRemoteClientInvoker and org.jboss.remoting.LeasePinger introduced a race condition. Each PING sends the list of all current client leases, which is used to update the list of clients leases in org.jboss.remoting.Lease.  It is possible for one thread to send a PING with a client list from which a client lease has been removed and for that list to arrive before the server gets the request to terminate that lease.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Fri Aug 17 18:58:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 17 Aug 2007 18:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1077) Decision tables
 to have ruleflow-group attribute column
In-Reply-To: <30015767.1186969861144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19887352.1187391481162.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer resolved JBRULES-1077.
-------------------------------------

    Resolution: Done

Added support for ruleflow group when column starts with R or is named RULEFLOW-GROUP 

> Decision tables to have ruleflow-group attribute column
> -------------------------------------------------------
>
>                 Key: JBRULES-1077
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1077
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Fernando Meyer
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> In decision tables, we can set no-loop attributes (amongst others) by haveing a special keyword in a column (chekc the code for how this is done). Would like to add ruleflow-group to this 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 lists.jboss.org  Fri Aug 17 20:07:01 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 17 Aug 2007 20:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1098) Add action
	support in ruleflow
Message-ID: <32055007.1187395621227.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add action support in ruleflow
------------------------------

                 Key: JBRULES-1098
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1098
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Rule Flow
            Reporter: Kris Verlaenen
         Assigned To: Kris Verlaenen
             Fix For: FUTURE


There should be an action node which simply executes the contained action when it is encountered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23480718.1187404261839.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-785:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.CR1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7729084.1187404261972.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-766:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s:     (was: 2.2.0.SP4_CP02)

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-761) NPE in
 BisocketServerInvoker$ControlConnectionThread
In-Reply-To: <9608977.1183001997620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18078601.1187404262089.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-761:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> NPE in BisocketServerInvoker$ControlConnectionThread
> ----------------------------------------------------
>
>                 Key: JBREM-761
>                 URL: http://jira.jboss.com/jira/browse/JBREM-761
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> From Tim Fox:
> Here's one I saw today:
> @main 18:11:54,129 INFO  [FailoverTest] tearing down
> Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException
>        at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669)
> It seems pretty harmless, but nevertheless I thought I'd inform 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 lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-778)
 BisocketServerInvoker.start() creates a new static Timer each time
In-Reply-To: <3736496.1184968967071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15399209.1187404262358.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-778:
----------------------------

    Fix Version/s: 2.2.2.GA
                   2.4.0.CR1 (Pinto)
                       (was: 2.4.0.Beta1 (Pinto))
                       (was: 2.2.0.SP4_CP02)
                       (was: 2.2.1.SP1)

> BisocketServerInvoker.start() creates a new static Timer each time
> ------------------------------------------------------------------
>
>                 Key: JBREM-778
>                 URL: http://jira.jboss.com/jira/browse/JBREM-778
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start() creates a new static Timer each time.  It should only create a new Timer if (1) there is no existing Timer, or (2) the existing Timer has shut down.  See the similar issue JBREM-748.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4921951.1187404262637.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-787:
----------------------------

    Fix Version/s: 2.2.2.GA
                   2.4.0.CR1 (Pinto)
                       (was: 2.4.0.Beta1 (Pinto))
                       (was: 2.2.0.SP4_CP02)
                       (was: 2.2.1.SP1)

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16287270.1187404262790.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-783:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.1.GA
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.CR1 (Pinto)
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9463198.1187404262950.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-790:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.4.0.Beta1 (Pinto)

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18888518.1187404263088.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-782:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.2.1.SP1)
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.4.0.Beta1 (Pinto))
    Affects Version/s: 2.2.1.GA
                           (was: 2.2.1.SP1)
                           (was: 2.2.0.SP4_CP02)

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19824385.1187404263266.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-765:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31520097.1187404263518.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-788:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29837971.1187404263705.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-793:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                       2.4.0.Beta1 (Pinto)
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7171563.1187404263848.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-789:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA
                       2.4.0.Beta1 (Pinto)
                           (was: 2.2.1.SP1)

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 17 22:31:04 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22528869.1187404264027.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-767:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.1.SP1)

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Fri Aug 17 22:31:04 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17404896.1187404264280.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-775:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-784) Use separate maps
 for control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4725159.1187404263396.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-784:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.4.0.Beta1 (Pinto)

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:04 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-774)
 BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should
 close control socket
In-Reply-To: <6131196.1184213431580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27289085.1187404264157.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-774:
----------------------------

    Fix Version/s: 2.2.2.GA
                   2.4.0.CR1 (Pinto)
                       (was: 2.4.0.Beta1 (Pinto))
                       (was: 2.2.0.SP4_CP02)
                       (was: 2.2.1.SP1)

> BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should close control socket
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBREM-774
>                 URL: http://jira.jboss.com/jira/browse/JBREM-774
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> If cpu overload or network congestion causes a control connection PING to get delayed, the client side org.jboss.remoting.transport.bisocket.Bisocket.BisocketServerInvoker.ControlMonitorTimerTask will tell the server side BisocketServerInvoker.SecondaryServerSocketThread to replace the control socket.  
> If org.jboss.remoting.transport.bisocket.Bisocket.BisocketClientInvoker.replaceControlSocket() does not close the old control socket, and if the client is still alive, the client side BisocketServerInvoker.ControlConnectionThread will be blocked trying to read from an old control connection, which is no longer in use on the server side.
> Also, BisocketClientInvoker.handleDisconnect() should close the control socket.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:37:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.2.GA
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23671420.1187404621104.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-789:
----------------------------

    Summary: Release 2.2.2.GA  (was: Release 2.2.1.SP1)

Changed from 2.2.1.SP1 to 2.2.2.GA

> Release 2.2.2.GA
> ----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 17 22:41:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-641) re-implement the
 callback polling for http transport to reduce latency
In-Reply-To: <4571412.1164899455840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6799043.1187404861370.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal reopened JBREM-641:
-----------------------------

             
Changes ported for release 2.2.2.GA.

> re-implement the callback polling for http transport to reduce latency
> ----------------------------------------------------------------------
>
>                 Key: JBREM-641
>                 URL: http://jira.jboss.com/jira/browse/JBREM-641
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon), 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:41:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-641) re-implement the
 callback polling for http transport to reduce latency
In-Reply-To: <4571412.1164899455840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3905959.1187404861623.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-641:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA
                       2.4.0.Beta1 (Pinto)

> re-implement the callback polling for http transport to reduce latency
> ----------------------------------------------------------------------
>
>                 Key: JBREM-641
>                 URL: http://jira.jboss.com/jira/browse/JBREM-641
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon), 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4282123.1187405472554.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-790:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-784) Use separate maps
 for control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15634231.1187405472663.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-784:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5918666.1187405472777.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-787:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4854528.1187405472905.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-788:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4470854.1187405473060.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-765:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8071912.1187405473166.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-782:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1670455.1187405473289.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-785:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-778)
 BisocketServerInvoker.start() creates a new static Timer each time
In-Reply-To: <3736496.1184968967071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9236954.1187405473412.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-778:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> BisocketServerInvoker.start() creates a new static Timer each time
> ------------------------------------------------------------------
>
>                 Key: JBREM-778
>                 URL: http://jira.jboss.com/jira/browse/JBREM-778
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start() creates a new static Timer each time.  It should only create a new Timer if (1) there is no existing Timer, or (2) the existing Timer has shut down.  See the similar issue JBREM-748.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-761) NPE in
 BisocketServerInvoker$ControlConnectionThread
In-Reply-To: <9608977.1183001997620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32979303.1187405473512.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-761:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> NPE in BisocketServerInvoker$ControlConnectionThread
> ----------------------------------------------------
>
>                 Key: JBREM-761
>                 URL: http://jira.jboss.com/jira/browse/JBREM-761
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> From Tim Fox:
> Here's one I saw today:
> @main 18:11:54,129 INFO  [FailoverTest] tearing down
> Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException
>        at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669)
> It seems pretty harmless, but nevertheless I thought I'd inform 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 lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9740980.1187405473628.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-783:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16633688.1187405473780.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-767:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.2.GA
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26195661.1187405473897.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-789:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Release 2.2.2.GA
> ----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2039752.1187405474033.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-766:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6069949.1187405474154.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-793:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15186051.1187405474293.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-775:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-774)
 BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should
 close control socket
In-Reply-To: <6131196.1184213431580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19123692.1187405474430.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-774:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should close control socket
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBREM-774
>                 URL: http://jira.jboss.com/jira/browse/JBREM-774
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If cpu overload or network congestion causes a control connection PING to get delayed, the client side org.jboss.remoting.transport.bisocket.Bisocket.BisocketServerInvoker.ControlMonitorTimerTask will tell the server side BisocketServerInvoker.SecondaryServerSocketThread to replace the control socket.  
> If org.jboss.remoting.transport.bisocket.Bisocket.BisocketClientInvoker.replaceControlSocket() does not close the old control socket, and if the client is still alive, the client side BisocketServerInvoker.ControlConnectionThread will be blocked trying to read from an old control connection, which is no longer in use on the server side.
> Also, BisocketClientInvoker.handleDisconnect() should close the control socket.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:55:20 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:55:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-756) CallbackPoller
 should shut down if too many errors occur.
In-Reply-To: <21704098.1182228191615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7118405.1187405720315.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal reopened JBREM-756:
-----------------------------

             
Changes applied to Remoting 2.2.2.GA.

> CallbackPoller should shut down if too many errors occur.
> ---------------------------------------------------------
>
>                 Key: JBREM-756
>                 URL: http://jira.jboss.com/jira/browse/JBREM-756
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.callback.CallbackPoller will keep running even if the connection is broken or server crashes.  It should be possible to specify a maximum number of errors, after which CallbackPoller will quit polling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:55:20 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:55:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-756) CallbackPoller
 should shut down if too many errors occur.
In-Reply-To: <21704098.1182228191615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24221834.1187405720428.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-756:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> CallbackPoller should shut down if too many errors occur.
> ---------------------------------------------------------
>
>                 Key: JBREM-756
>                 URL: http://jira.jboss.com/jira/browse/JBREM-756
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.callback.CallbackPoller will keep running even if the connection is broken or server crashes.  It should be possible to specify a maximum number of errors, after which CallbackPoller will quit polling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:57:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-743) For polling callback
 handler, 
 org.jboss.remoting.Client.addListener() should create only one
 CallbackPoller per InvokerCallbackHandler
In-Reply-To: <28950543.1178341672458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3389313.1187405821238.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-743:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

Changes ported for Remoting 2.2.2.GA.

> For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-743
>                 URL: http://jira.jboss.com/jira/browse/JBREM-743
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. 
> The semantics, according to Chapter 5 of the Remoting guide, should be
> If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect.
> So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:57:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-755) Make
 ConnectorValidator parameters configurable
In-Reply-To: <9961988.1181953572529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23265073.1187405821413.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal reopened JBREM-755:
-----------------------------

             
Changes ported for Remoting 2.2.2.GA.

> Make ConnectorValidator parameters configurable
> -----------------------------------------------
>
>                 Key: JBREM-755
>                 URL: http://jira.jboss.com/jira/browse/JBREM-755
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Currently org.jboss.remoting.ConnectionValidator hard codes the timeout value (1000 ms) and the number of attempts (1) to get a socket (socket transport family only).  It would be useful to be able to configure these parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:57:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-755) Make
 ConnectorValidator parameters configurable
In-Reply-To: <9961988.1181953572529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9854443.1187405821577.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-755:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> Make ConnectorValidator parameters configurable
> -----------------------------------------------
>
>                 Key: JBREM-755
>                 URL: http://jira.jboss.com/jira/browse/JBREM-755
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Currently org.jboss.remoting.ConnectionValidator hard codes the timeout value (1000 ms) and the number of attempts (1) to get a socket (socket transport family only).  It would be useful to be able to configure these parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:59:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22605568.1187405941052.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-757:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

Changes ported for Remoting 2.2.2.GA.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 23:01:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-754) Reset timeout on
 each use of HttpURLConnection
In-Reply-To: <3212428.1181272151600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3410829.1187406061267.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal reopened JBREM-754:
-----------------------------

             
Changes ported for Remoting 2.2.2.GA.

> Reset timeout on each use of HttpURLConnection
> ----------------------------------------------
>
>                 Key: JBREM-754
>                 URL: http://jira.jboss.com/jira/browse/JBREM-754
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Even though each call to org.jboss.remoting.transport.http.HTTPClientInvoker.invoke() creates a new HttpURLConnection, it seems that the HttpURLConnection implementation caches underlying connections.  When an org.jboss.remoting.ConnectionValidator is running, it connects to the same server as ordinary HTTPClientInvokers used by the application, but it sets a timeout of 1000.  If no timeout value is configured for application connections, then HTTPClientInvoker does not set a timeout on the HttpURLConnection, and a connection with a timeout of 1000 might get reused.
> If no timeout is configured, HTTPClientInvoker should explicitly set the HttpURLConnection connect and read timeouts to 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 lists.jboss.org  Fri Aug 17 23:01:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-754) Reset timeout on
 each use of HttpURLConnection
In-Reply-To: <3212428.1181272151600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13648507.1187406061419.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-754:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> Reset timeout on each use of HttpURLConnection
> ----------------------------------------------
>
>                 Key: JBREM-754
>                 URL: http://jira.jboss.com/jira/browse/JBREM-754
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Even though each call to org.jboss.remoting.transport.http.HTTPClientInvoker.invoke() creates a new HttpURLConnection, it seems that the HttpURLConnection implementation caches underlying connections.  When an org.jboss.remoting.ConnectionValidator is running, it connects to the same server as ordinary HTTPClientInvokers used by the application, but it sets a timeout of 1000.  If no timeout value is configured for application connections, then HTTPClientInvoker does not set a timeout on the HttpURLConnection, and a connection with a timeout of 1000 might get reused.
> If no timeout is configured, HTTPClientInvoker should explicitly set the HttpURLConnection connect and read timeouts to 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 lists.jboss.org  Fri Aug 17 23:01:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21130247.1187406061556.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-771:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 23:32:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-747)
 org.jboss.remoting.transport.Connector should unregister server invoker
 from MBeanServer
In-Reply-To: <8850851.1179472312226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6620747.1187407921103.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal reopened JBREM-747:
-----------------------------

             
Changing fix version from 2.2.1.SP1 to 2.2.2.GA.

> org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-747
>                 URL: http://jira.jboss.com/jira/browse/JBREM-747
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one).  
> The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception 
> javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
>         at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799)
> The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered.  The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker.   As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory 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 lists.jboss.org  Fri Aug 17 23:32:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-747)
 org.jboss.remoting.transport.Connector should unregister server invoker
 from MBeanServer
In-Reply-To: <8850851.1179472312226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22702926.1187407921216.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-747:
----------------------------

    Fix Version/s: 2.2.2.GA
                       (was: 2.2.1.SP1)

> org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-747
>                 URL: http://jira.jboss.com/jira/browse/JBREM-747
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one).  
> The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception 
> javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
>         at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799)
> The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered.  The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker.   As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory 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 lists.jboss.org  Sat Aug 18 03:37:11 2007
From: jira-events at lists.jboss.org (Gernot Starke (JIRA))
Date: Sat, 18 Aug 2007 03:37:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1099) Split
 documentation in "reference manual" and "user guide"
Message-ID: <13593324.1187422631455.JavaMail.jira@cloud.prod.atl2.jboss.com>

Split documentation in "reference manual" and "user guide"
----------------------------------------------------------

                 Key: JBRULES-1099
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1099
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation
         Environment: all
            Reporter: Gernot Starke
         Assigned To: Mark Proctor
            Priority: Minor


imho documentation for a product like JBoss Drools should consist of several DISTINCT parts,
at least reference manual and user guide.

That'd make it two different manuals - but especially the language documentation should get
a more promininent location... (reference manual)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 04:20:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sat, 18 Aug 2007 04:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25962980.1187425201281.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372845 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Okay I suddenly see what you mean.
So when the AOPC process needs more artifacts I should add them to the plugin !!!!

I think this is because I understand too little of AOP
So what you mean is that classes needed by AOPC (from my dependent artifacts) might only be needed at AOP compile time, and NOT at runtime.

I would need some testing (of the portal application) to getting this right or wrong.

I still think the project compile classpath should be added to the "AOPC -cp" just in case a class should be used both places. This is (as I see it) a consequence of adding the project.getBuild().getOutputDirectory().

Consider I re-factored my artifact into several artifacts, I should still be able to build it. And in this case some of the refactored classes will come from a project dependency.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Sat Aug 18 05:55:01 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Sat, 18 Aug 2007 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1632) Impossible to
 deactivate registration in WSRP producer configuration.
In-Reply-To: <1352609.1187257381672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28927079.1187430901145.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun resolved JBPORTAL-1632.
------------------------------------

    Resolution: Done

> Impossible to deactivate registration in WSRP producer configuration.
> ---------------------------------------------------------------------
>
>                 Key: JBPORTAL-1632
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1632
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Empty producer-configuration is not authorized in the DTD, in particular.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 08:09:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Sat, 18 Aug 2007 08:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16179303.1187438941194.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Ronald van Kuijk reopened JBPM-1042:
------------------------------------

             
Hmmm... maybe  a wrong assumption on my side. In one of my local tests where I get this token locked error, it is fixed by the checkins in cvs. I'll reopen and investigate some more

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 08:12:04 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Sat, 18 Aug 2007 08:12:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19284885.1187439124844.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boleslaw Dawidowicz reopened JBPORTAL-1614:
-------------------------------------------

             
I needed to rolback this commit for now as testsuite was failing and there were deployment issues. Maybe some other stuff conflicted with it

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 10:28:15 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Aug 2007 10:28:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4613) JBossCacheManager
 active session count should include backup sessions
Message-ID: <6215880.1187447295367.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossCacheManager active session count should include backup sessions
---------------------------------------------------------------------

                 Key: JBAS-4613
                 URL: http://jira.jboss.com/jira/browse/JBAS-4613
             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.Beta3


The usage of the max active session configuration in JBossCacheManager currently only applies to sessions that are being used in the local node -- it ignores how many sessions are stored in the distributed cache.  This makes little sense, since the primary purpose of controlling the session count is to control memory resources.  A session in the distributed cache takes memory resources just as much as a locally used one does.

With this change, when the Manager checks whether there are excess sessions, the maxActive property value will be compared against an "active" count derived as follows:

visible sessions = count of locally accessed sessions + count of sessions in the local instance of the distributed cache that have not been locally accessed
active sessions = visible sessions - sessions passivated locally

The value of that calculation is what will be returned by the getActiveSessionCount() method.

If the active session count >= maxActive, the session expiration/passivation method (processExpires()) will be executed before a new session is created.  If after expiration/passivation the active session count still exceeds maxActive, the session creation request will be rejected with an IllegalStateException. (Rejecting the attempt to create excess sessions is not new; all that has changed is the calculation.) 

The same comparison is used within processExpires() to determine whether sessions that have reached their configured passivation-min-idle-time need to be passivated.

Note that the value of "active sessions" will depend on whether the distributed cache is using buddy replication, as that will impact the number of sessions stored in the local instance of the distributed cache:

1) If buddy replication is disabled, a copy of all sessions used on any node in the cluster will be stored in the local instance of the distributed cache.

2) If buddy replication is enabled (the default in 5.x), only sessions hosted by cluster nodes for which the current node is serving as a buddy will be stored in the local instance of the distributed cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 11:06:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sat, 18 Aug 2007 11:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1615) Maven2 poms
 initial version ready for portal
In-Reply-To: <4157740.1185486047091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31041773.1187449561670.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anders Andersen updated JBPORTAL-1615:
--------------------------------------

    Attachment: _maven-08-18.tar.gz

Updated to todays trunk
fixed:
1)  core-admin test war and sar is build
2)  AOPC plugin seems now to work fully
3)  intelliJ files are removed from "kit" (use mvn idea:idea to establish em)


> Maven2 poms initial version ready for portal
> --------------------------------------------
>
>                 Key: JBPORTAL-1615
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1615
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>         Environment: unix script used (use unix or cygwin)
>            Reporter: Anders Andersen
>         Attachments: _maven-08-05.tar.gz, _maven-08-18.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz
>
>          Time Spent: 1 day, 5 hours
>  Remaining Estimate: 0 minutes
>
> The _maven directory will contain a complete maven2 build environment for the jboss portal
> prepare:
>           If you are running windows --> install cygwin and run bash from here
>           1) #install maven2 (2.0.6) or later
>           2) #install the jboss-packaging-maven-plugin
>              svn co https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/jboss-packaging-maven-plugin jboss-packaging-maven-plugin
>              mvn -f jboss-packaging-maven-plugin/pom.xml install
>           3) #install the portal
>              svn co http://anonsvn.jboss.org/repos/portal/trunk jboos-portal
>              cd jboss-portal
>              build/build.sh clean most
>           4) unzip the _maven into jboss-portal
>           5) cd _maven
>              cd _deploy
>              # deploy the third party artifacts that I did not find on the internet
>              # edit the script to meet your settings before running
>              ./third-party-deploy.sh
>           6) #prepare the maven source locations
> usage:       #run script
>              ./_build.sh
> post steps:
>           7) #maven build the jboss 2.6 portal
>              mvn clean install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 12:07:16 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Sat, 18 Aug 2007 12:07:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1100) BRMS Bug on view
 source in weblogic
Message-ID: <10407110.1187453236080.JavaMail.jira@cloud.prod.atl2.jboss.com>

BRMS Bug on view source in weblogic
-----------------------------------

                 Key: JBRULES-1100
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1100
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA,  4.0.0.MR3, 4.0.0.MR2
         Environment: OS: Any 
Application Server: Weblogic > 9.2
            Reporter: Fernando Meyer
         Assigned To: Fernando Meyer
             Fix For: 4.0.1


When trying to view source brms is using eclipse instead janino

|####<Aug 18, 2007 1:59:34 AM BRT> <Error> <ServletContext-/drools-jbrms> <localhost.localdomain> <examplesServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1187413174144> <000000> <Exception while dispatching incoming RPC call
org.drools.RuntimeDroolsException: Unable to load dialect ' org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java'
        at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:138)
        at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
        at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
        at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
        at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
        at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
        at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
        at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
        at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
        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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
        at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
java.lang.RuntimeException : The Eclipse JDT Core jar is not in the classpath
        at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.setCompiler(JavaDialectConfiguration.java:98)
        at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.init (JavaDialectConfiguration.java:56)
        at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:134)
        at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
        at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
        at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
        at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
        at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
        at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
        at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
        at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
        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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
        at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 12:18:15 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Sat, 18 Aug 2007 12:18:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1100) BRMS Bug on view
 source in weblogic
In-Reply-To: <10407110.1187453236080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22950921.1187453895033.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer resolved JBRULES-1100.
-------------------------------------

    Resolution: Done

> BRMS Bug on view source in weblogic
> -----------------------------------
>
>                 Key: JBRULES-1100
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1100
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.0.MR2,  4.0.0.MR3,  4.0.0.GA
>         Environment: OS: Any 
> Application Server: Weblogic > 9.2
>            Reporter: Fernando Meyer
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> When trying to view source brms is using eclipse instead janino
> |####<Aug 18, 2007 1:59:34 AM BRT> <Error> <ServletContext-/drools-jbrms> <localhost.localdomain> <examplesServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1187413174144> <000000> <Exception while dispatching incoming RPC call
> org.drools.RuntimeDroolsException: Unable to load dialect ' org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java'
>         at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:138)
>         at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
>         at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
>         at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
>         at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
>         at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
>         at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
>         at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
>         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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
>         at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
> java.lang.RuntimeException : The Eclipse JDT Core jar is not in the classpath
>         at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.setCompiler(JavaDialectConfiguration.java:98)
>         at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.init (JavaDialectConfiguration.java:56)
>         at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:134)
>         at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
>         at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
>         at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
>         at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
>         at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
>         at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
>         at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
>         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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
>         at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 14:13:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 18 Aug 2007 14:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1045) Predicate Null
 Pointer exception when using Java 5 Enum
In-Reply-To: <11289278.1185770821666.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4873229.1187460781251.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1045.
----------------------------------

    Resolution: Done

Fixed. Parser dos not accept invalid constructs like that anymore. Unit test added.

> Predicate Null Pointer exception when using Java 5 Enum
> -------------------------------------------------------
>
>                 Key: JBRULES-1045
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1045
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, Jboss Rules 4.0.0 GA, Sun Java 1.5.0_11 VM, Eclipse 3.3 with JBOss Rules IDE 4.0 
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Java 5 enums as column constraint do not work as expected.  Cqauses Null pointer exception in mvel.MVELPredicateExpression.evaluate.
> Using modified Eclipse generated  Sample project to demonstrate:
> DroolsTest now has an Enum for it's Message:
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.insert(Message.HELLO);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         // read in the source
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/Sample.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
>     public enum Message {
>         GOODBYE, HELLO;
>     }
> }
> The Sample.drl rule is modified to:
> package com.sample
> import com.sample.DroolsTest.Message;
> rule "Hello World"
>   when
>     m : Message( Message.HELLO )
>   then
>     System.out.println( m );
> end
> Stack trace given is:
> org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 10382a9
> 	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:21)
> Caused by: java.lang.NullPointerException
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:39)
> 	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191)
> 	... 10 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 lists.jboss.org  Sat Aug 18 17:24:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Aug 2007 17:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4548) Testsuite failures
 due to EJBs starting before datasource
In-Reply-To: <21518359.1184384643755.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5466543.1187472241279.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I have added test org.jboss.test.deployers.ear.test.EmbeddedDatasourceUnitTestCase that shows this issue. With that in place I plan to modify the clustering tests mentioned in the above description to work around this issue.

> Testsuite failures due to EJBs starting before datasource
> ---------------------------------------------------------
>
>                 Key: JBAS-4548
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4548
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Deployment services
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Brian Stansberry
>         Assigned To: Dimitris Andreadis
>
> A number of unit tests are failing due to EJB2 deployment failures.  The tests deploy an ear; contents of the ear are an ejb2 jar and a -ds.xml file.  The ejb jar is deploying before the datasource, and thus ejb deployment fails when the datasource cannot be found in JNDI.
> See forum thread for detailed discussion.
> The testsuite failures due to this that I'm aware of are:
> org.jboss.test.testbeancluster.test.CacheInvalidationUnitTestCase
> org.jboss.test.testbeancluster.test.RetryInterceptorUnitTestCase
> org.jboss.test.testbeancluster.test.SingleRetryInterceptorUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 23:28:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Aug 2007 23:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4614)
 UnifiedInvokerHAProxy does not implement InvokerProxyHA
Message-ID: <9418263.1187494081162.JavaMail.jira@cloud.prod.atl2.jboss.com>

UnifiedInvokerHAProxy does not implement InvokerProxyHA
-------------------------------------------------------

                 Key: JBAS-4614
                 URL: http://jira.jboss.com/jira/browse/JBAS-4614
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


UnifiedInvokerHAProxy does not implement InvokerProxyHA.  Because of this, ProxyFactoryHA will not update a unified invoker proxy's target list when it gets a notification of a cluster topology change.  Effect is a client downloading the proxy will always get the set of targets available when the proxy was created.

Usually the downloaded proxy will also have at least one valid target (the one for the node that created the proxy.) As soon as the client makes an invocation, the server will detect they have a stale view and piggyback the current targets with the response. So, this bug is not very likely to cause an invocation failure, but it does reduce the robustness of the proxy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 01:32:01 2007
From: jira-events at lists.jboss.org (Yuri de Wit (JIRA))
Date: Sun, 19 Aug 2007 01:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
Message-ID: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>

MVEL direct property accessors being converted to a ReturnValueConstraint
-------------------------------------------------------------------------

                 Key: JBRULES-1101
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Yuri de Wit
         Assigned To: Mark Proctor


After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.

So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 01:36:01 2007
From: jira-events at lists.jboss.org (Yuri de Wit (JIRA))
Date: Sun, 19 Aug 2007 01:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1102) Bug in
 DefaultBetaConstraint class indexing to never turn on
Message-ID: <22237245.1187501761200.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bug in DefaultBetaConstraint class indexing to never turn on
------------------------------------------------------------

                 Key: JBRULES-1102
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1102
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Yuri de Wit
         Assigned To: Mark Proctor


Look at line 75 of DefaultBetaConstraint: notice the (depth <= this.indexed). This will always evaluate to false. It should be this.indexed < depth

This bug and the one reported here (http://jira.jboss.com/jira/browse/JBRULES-1101) make sure that indexing is not used 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 lists.jboss.org  Sun Aug 19 04:13:01 2007
From: jira-events at lists.jboss.org (Wise Guy (JIRA))
Date: Sun, 19 Aug 2007 04:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-70)
 Interceptor.onLoad not called from EJB3 event listeners
Message-ID: <26959250.1187511181135.JavaMail.jira@cloud.prod.atl2.jboss.com>

Interceptor.onLoad not called from EJB3 event listeners
-------------------------------------------------------

                 Key: HIBERNATE-70
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-70
             Project: Hibernate
          Issue Type: Bug
         Environment: JBoss 4.2.1.GA, Hibernate 3.2.1 SP1, Seam 1.2.1.GA
            Reporter: Wise Guy
         Assigned To: Steve Ebersole
            Priority: Minor


I have a Seam 1.2.1.GA application. I installed an implementation of the interface org.hibernate.Interceptor and declared it in the persistence.xml as hibernate.ejb.interceptor.

The interceptor works (ex.: onSave(), onFlushDirty()) except that onLoad() doesn't get called. 

I guess that there is a problem with the DefaultPreLoadEventListener who should call my interceptor. He is defined in org.hibernate.event.EventListeners as a default listener to the event "pre-load". I also found that the DefaultLoadEventListener.onLoad() gets called but DefaultPreLoadEventListener.onPreLoad() not. Does that have something to do with EJB3? I have found that there is an EJB3PostLoadEventListener that is used when run under JPA and the default listeners are overridden.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 11:17:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Aug 2007 11:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-642) Extract solver
	configuration
In-Reply-To: <33397392.1170512250040.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18199450.1187536621231.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet resolved JBRULES-642.
--------------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

fixed

> Extract solver configuration
> ----------------------------
>
>                 Key: JBRULES-642
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-642
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Solver
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 4.0.1
>
>
> Preferable into an xml file.
> Should help to make the integration tests easier 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 lists.jboss.org  Sun Aug 19 11:19:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Aug 2007 11:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-678) Remove spring
	dependency
In-Reply-To: <4908345.1171728569969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30881876.1187536741065.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet resolved JBRULES-678.
--------------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

fixed

> Remove spring dependency
> ------------------------
>
>                 Key: JBRULES-678
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-678
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Solver
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Once the configuration xml is extracted this should be a peice of cake

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 11:21:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Aug 2007 11:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1103) Tabu asperation
 based on stepscore
Message-ID: <19288912.1187536861044.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tabu asperation based on stepscore
----------------------------------

                 Key: JBRULES-1103
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1103
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Solver
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
             Fix For: FUTURE


Move tabu and property tabu could use "aspiration"
Basically even if it's tabu, a move is accepted if the stepscore improves.

For solution tabu this is pointless.
Aspiration should occur on stepScore and NOT on decisionScore

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 15:45:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Sun, 19 Aug 2007 15:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1606) Portlet and
 service to see current users online
In-Reply-To: <7812771.1185034607642.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <827527.1187552701857.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boleslaw Dawidowicz resolved JBPORTAL-1606.
-------------------------------------------

    Resolution: Done

commited. I also added support for cluster environment using ha jmx notifications

> Portlet and service to see current users online
> -----------------------------------------------
>
>                 Key: JBPORTAL-1606
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1606
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal Samples
>    Affects Versions: 2.6 Final
>         Environment: developed with Eclipse 3.2.2 and jboss portal from http://anonsvn.jboss.org/repos/portal/tags/JBoss_Portal_2_6_0
>            Reporter: Luca Stancapiano
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 Final
>
>         Attachments: UsersOnline.zip, UsersOnline.zip, UsersOnline.zip
>
>
> I developed together with Bolek a portlet and service to see current users online.
> UI part is into portal-samples project. Modified and added files are:
> // descriptors for portlet......I add portal-lib.tld to get support for i18n and Context to send info from portlet to jsp
> core-samples/src/resources/portal-users-samples-war/WEB-INF/portlet.xml
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jboss-portlet.xml
> core-samples/src/resources/portal-users-samples-war/WEB-INF/portal-lib.tld
> core-samples/src/resources/portal-users-samples-war/WEB-INF/portlet-instances.xml
> // I create three jsp....one when no user is online, one when there is a only user online and one for all other users online
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jsp/users/oneUser.jsp
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jsp/users/users.jsp
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jsp/users/noUser.jsp
> // I add support for i18n with english and italian language
> core-samples/src/resources/portal-users-samples-war/WEB-INF/classes/Resource.properties
> core-samples/src/resources/portal-users-samples-war/WEB-INF/classes/Resource_it.properties
> // this is a simple portlet that call a UserActivityService that schedule activities of users. This portlet print current users online and number of current users online
> core-samples/src/main/org/jboss/portal/core/samples/users/CurrentUsersPortlet.java
> // I updated build.xml to build portal-users-samples.war package to deploy it into application server
> core-samples/build.xml
> part about service and interceptor is into core:
> // we add UsersActivityStatsService service and UserStats interceptor. The interceptor is added into InterceptorStackFactory,type=Server of jboss portal to catch all activities of users.
> // rows updated are: 
> core/src/resources/portal-core-sar/META-INF/jboss-service.xml
> // classes for  UsersActivityStatsService service. There are an interface of service, an implementation and a class that represents an user activity registered into the service
> core/src/main/org/jboss/portal/core/identity/UsersActivityStatsServiceImpl.java
> core/src/main/org/jboss/portal/core/identity/UsersActivityStatsService.java
> core/src/main/org/jboss/portal/core/identity/UserActivity.java
> // this is UserStats interceptor
> core/src/main/org/jboss/portal/core/aspects/server/UserStatsInterceptor.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 lists.jboss.org  Sun Aug 19 18:44:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Sun, 19 Aug 2007 18:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1077) Decision tables to
 have ruleflow-group attribute column
In-Reply-To: <30015767.1186969861144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28283074.1187563441196.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-1077.
----------------------------------


Closing issue as mark likes things to be closed when done (we aren't really sure what resolved means - if something regresses we can re-open a closed one anyway - I think resolved is when there is a traditional testing/QA department and they have to sign off that it was indeed done).

> Decision tables to have ruleflow-group attribute column
> -------------------------------------------------------
>
>                 Key: JBRULES-1077
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1077
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Fernando Meyer
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> In decision tables, we can set no-loop attributes (amongst others) by haveing a special keyword in a column (chekc the code for how this is done). Would like to add ruleflow-group to this 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 lists.jboss.org  Sun Aug 19 22:18:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 19 Aug 2007 22:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1104) Inserted Objects
 are lost if no matching ObjectTypeNodes
Message-ID: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>

Inserted Objects are lost if no matching ObjectTypeNodes
--------------------------------------------------------

                 Key: JBRULES-1104
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 22:42:05 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 19 Aug 2007 22:42:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4615) NamingContext caches
 stale Naming stub
Message-ID: <17323116.1187577725144.JavaMail.jira@cloud.prod.atl2.jboss.com>

NamingContext caches stale Naming stub
--------------------------------------

                 Key: JBAS-4615
                 URL: http://jira.jboss.com/jira/browse/JBAS-4615
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3


As an important performance optimization, org.jnp.interfaces.NamingContext statically caches a WeakReference to the "proxy" to the server-side Naming service.  In most cases this is either an RMI stub (non-HA naming service) or a proxy based on an HARMIClient (for HA-JNDI).  Either way, the cached object uses RMI to communicate with the server.

This object becomes invalid if the server (non-HA case) or cluster (HA case) it was associated with is restarted.  The object in the restarted server-side RMI runtime will no longer match the client-side RMI stub, and an invocation over the stub will result in a java.rmi.NoSuchObjectException on the client.  NamingContext's caching of the RMI greatly increases the odds of this occuring.  If this occurs, the cache will be flushed and the next call will acquire a fresh stub from the server, but the client will get an exception on the first call.

Proposed solution is discussed on forum thread.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 23:12:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 19 Aug 2007 23:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4616) NamingContext
 lookupLink() does not acquire stub to server Naming service
Message-ID: <10742725.1187579521074.JavaMail.jira@cloud.prod.atl2.jboss.com>

NamingContext lookupLink() does not acquire stub to server Naming service
-------------------------------------------------------------------------

                 Key: JBAS-4616
                 URL: http://jira.jboss.com/jira/browse/JBAS-4616
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3


org.jnp.interfaces.NamingContext.lookupLink(Name) does not invoke the checkRef() method before invoking on the stub to the server-side Naming object.  The checkRef() method is what actually contacts the JNDI server to download the stub.. Result of this is an NPE will be thrown if an earlier call hasn't downloaded the stub before lookupLink() 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 lists.jboss.org  Mon Aug 20 00:46:17 2007
From: jira-events at lists.jboss.org (Michael Max (JIRA))
Date: Mon, 20 Aug 2007 00:46:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1105) web.xml does not
 conform web-app_2_3.dtd
Message-ID: <3916092.1187585177133.JavaMail.jira@cloud.prod.atl2.jboss.com>

web.xml does not conform web-app_2_3.dtd
----------------------------------------

                 Key: JBRULES-1105
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1105
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Glassfish
            Reporter: Michael Max
         Assigned To: Mark Proctor
             Fix For:  4.0.0.GA


web.xml does not comply with a http://java.sun.com/dtd/web-app_2_3.dtd specification. Because of that drools-jbrms.war cannot be deployed to the servers with a strict validation as Glassfish, just to JBoss AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 01:28:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 20 Aug 2007 01:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-794)
 LeasePinger.addClient() should
 not create a new LeaseTimerTask if none currently exists
Message-ID: <18755133.1187587681051.JavaMail.jira@cloud.prod.atl2.jboss.com>

LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists
---------------------------------------------------------------------------------------

                 Key: JBREM-794
                 URL: http://jira.jboss.com/jira/browse/JBREM-794
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)


When org.jboss.remoting.LeasePinger.addClient() adds a new org.jboss.remoting.Client with a shorter ping period, it restarts the LeaseTimerTask.  However, org.jboss.remoting.MicroRemoteClientInvoker.establishLease() calls LeasePinger.addClient() before it calls LeasePinger.startPing().  LeasePinger incorrectly creates a LeaseTimerTask in addClient() and then creates a second one in startPing().

LeasePinger.addClient() should be changed so that it starts a new LeaseTimerTask only if one already 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 lists.jboss.org  Mon Aug 20 01:37:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 01:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1097) Manual
 html_single does not have TOC entry for Chapter 9 BRMS
In-Reply-To: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30624662.1187588221225.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer reassigned JBRULES-1097:
---------------------------------------

    Assignee: Fernando Meyer  (was: Michael Neale)

> Manual html_single does not have TOC entry for Chapter 9 BRMS
> -------------------------------------------------------------
>
>                 Key: JBRULES-1097
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Jeff DeLong
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:05:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 20 Aug 2007 02:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20069174.1187589901060.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Actually, the first attempt introduced a race condition.  The solution is to move org.jboss.remoting.Client.connect() out of ServerInvokerCallbackHandler() into a new method, ServerInvokerCallbackHandler.connect().

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:12:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 20 Aug 2007 02:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8059683.1187590321526.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal updated JBREM-749:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:19:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 02:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1097) Manual html_single
 does not have TOC entry for Chapter 9 BRMS
In-Reply-To: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29027079.1187590741120.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer closed JBRULES-1097.
-----------------------------------

    Resolution: Done

missing chapter tag corrected

> Manual html_single does not have TOC entry for Chapter 9 BRMS
> -------------------------------------------------------------
>
>                 Key: JBRULES-1097
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Jeff DeLong
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:36:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3273080.1187591761138.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Added exponential_backoff, use_stats_for_retransmission, as explained in [1]

[1] http://www.jgroups.org/javagroupsnew/docs/manual/html/protlist.html#d0e3194

> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:36:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32971463.1187591761289.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-510.
---------------------------

    Resolution: Done

> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:38:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1068924.1187591881056.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Retransmission stats over time can be seen by enabling enable_xmit_time_stats. When the program is terminated, the stats will be dumped to a file suffixed by the address of the member. Note that, since all stats are kept in memory, memory will accumulate over time, so this property is only for diagnosis !

> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:40:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-180) Harden stack to
 prevent loss of intra-stack events
Message-ID: <7523123.1187592001317.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-180:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Haven't run into this scenario yet, so I move it to 2.x

> Harden stack to prevent loss of intra-stack events
> --------------------------------------------------
>
>                 Key: JGRP-180
>                 URL: http://jira.jboss.com/jira/browse/JGRP-180
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9, 2.2.9.1, 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> When an *intra-stack* event is lost, this can be serious (*inter-stack* message are simply retransmitted, so that is not critical).
> Losses are mainly caused by runtime exceptions, e.g. OutOfMemory exception (OOM), or resource problems, and to a lesser extent by program bugs.
> For example, when a user sends a message using Channel.send(), and there is an exception, then the user will simply send the message again, possibly after fixing the cause of the exception.
> However, for events such as VIEW_CHANGE that are multicast by the GMS protocol, a loss can be serious: in this case, the view would never be received !
> The same applies to the up direction: when NAKACK has successfully delivered a message, if that message is lost travelling between NAKACK and the Channel, then is serious (essentially loss of that message).
> So while these error situations don't occur very often, if they do occur, they have serious consequences.
> SOLUTION:
> - Do nothing for user messages: Channel.send() throws an exception, user has to resend message. Note that in http://jira.jboss.com/jira/browse/JGRP-179, we made retransmission handling atomic, e.g. if there is an exception, there will *not* be a gap in the seqnos for NAKACK and UNICAST
> - Provide either a pass{Up/Down}Reliably() method or an Event with a RELIABLE field, such that this event needs to be acked. The sender (e.g. GMS on a VIEW_CHANGE) sends down the message and waits until it gets an ACK, which could be sent by the NAKACK or UNICAST protocols, or as last resort by the transport (TP). If the ACK is not received within M ms, the event is resent. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:34:17 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 03:34:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-574) UnicastChannelTest
	doesn't work
In-Reply-To: <8228116.1187104561702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10628099.1187595257008.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fixed. However, currently flow control (FC) is not enabled for unicast connnections, we need to enable that later on (if a lot of people ever use unicast connections)

> UnicastChannelTest doesn't work
> -------------------------------
>
>                 Key: JGRP-574
>                 URL: http://jira.jboss.com/jira/browse/JGRP-574
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Messages are not received 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:34:17 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 03:34:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-574) UnicastChannelTest
	doesn't work
In-Reply-To: <8228116.1187104561702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13359930.1187595257156.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-574.
---------------------------

    Resolution: Done

> UnicastChannelTest doesn't work
> -------------------------------
>
>                 Key: JGRP-574
>                 URL: http://jira.jboss.com/jira/browse/JGRP-574
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Messages are not received 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:38:01 2007
From: jira-events at lists.jboss.org (Carsten Christensen (JIRA))
Date: Mon, 20 Aug 2007 03:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-425) Exception when
 an entity persisted and removed in the same JTA
Message-ID: <26306137.1187595481733.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-425?page=comments#action_12372898 ] 
            
Carsten Christensen commented on EJBTHREE-425:
----------------------------------------------

Hi, i still see this error, and none of the workarounds seems to work.

My Entity is in a inherritance heraki, where i have 

@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public abstract class Element implements Serializable
{	
	
	@Id
	@GeneratedValue
	@Column(name = "elementId", unique = true, nullable = false)
	@NotNull
	private int elementId;
	
	@ManyToOne(optional=true)
	@JoinColumn(name="pageId", nullable=false)
	private Page page;
.....
}

@Entity
public class ExtElement extends Element {

	//, cascade=CascadeType.ALL
	@OneToMany(fetch = FetchType.EAGER, mappedBy="explainText")
	@MapKey(name="languageId")
	private Map<Integer,ExtElementLanguage> extElementLanguages;
....
}


when i do 

em.remove(em.merge(element));

i get the error:

09:18:56,332 FATAL [application] javax.ejb.EJBTransactionRolledbackException: deleted entity passed to persist: [my.package.Element#<null>]
javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: deleted entity passed to persist: [my.package.Element#<null>]
	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:91)
......

This is badly influencing customers, do you have any solution?

have tried to split the line to em.merge(element); em.remove.element()
toss in flush and clear() etc



> Exception when an entity persisted and removed in the same JTA
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-425
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-425
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
>            Reporter: Jens Elkner
>
> JBoss/Hibernate throws an exception, if an entity is persisted and later removed in the same JTA, even when em.flush() has been called before removal.
> org.hibernate.ObjectDeletedException: deleted entity passed to persist ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:50:07 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 03:50:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-528) NAKACK: spurious
 retransmission requests
In-Reply-To: <29689518.1181634251598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13533095.1187596207325.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-528.
---------------------------

    Resolution: Cannot Reproduce Bug

In 2.6, I cannot reproduce this

> NAKACK: spurious retransmission requests 
> -----------------------------------------
>
>                 Key: JGRP-528
>                 URL: http://jira.jboss.com/jira/browse/JGRP-528
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> Every now and then, spurious retransmission requests are received:
> NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)]
> It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message.
> This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads).
> Note that this issue DOES NOT LEAD TO INCORRECT BEHAVIOR !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 07:18:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 07:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-462) NAKACK: remove
 bundling for retransmitted messages
In-Reply-To: <11395734.1175874298473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12002758.1187608681209.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-462.
---------------------------

    Resolution: Done

Simplification of code, performance is the same

> NAKACK: remove bundling for retransmitted messages
> --------------------------------------------------
>
>                 Key: JGRP-462
>                 URL: http://jira.jboss.com/jira/browse/JGRP-462
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> In NAKACK, all retransmitted messages are sent in batches (governed by max_xmit_size). This is redundant, as TP also provides bundling. A quick change of code showed that individual retransmissions is as fast as batched retransmission. This functionality can therefore 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 lists.jboss.org  Mon Aug 20 08:22:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 20 Aug 2007 08:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
In-Reply-To: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3989838.1187612521202.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf reassigned EJBTHREE-1031:
---------------------------------------

    Assignee: Carlo de Wolf  (was: William DeCoste)

> runaway SLSB instance creation with ThreadLocalPool
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1031
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Carlo de Wolf
>
> Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:38:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 08:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1150394.1187613481926.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1101:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:40:02 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 08:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10105402.1187613602240.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1101?page=comments#action_12372914 ] 
            
Edson Tirelli commented on JBRULES-1101:
----------------------------------------

Yuri,

Can you please show me one of your rules that were having such problem?

Thank you,
Edson

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:46:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 08:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1092) Invalid Java
 code generated from 'accumulate' function with nested classes
In-Reply-To: <22762348.1187266681169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13903360.1187613961815.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1092:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Invalid Java code generated from 'accumulate' function with nested classes
> --------------------------------------------------------------------------
>
>                 Key: JBRULES-1092
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1092
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>
> Steps to reproduce:
> - Create a sample new project with the Eclipse plugin
> - Add following rule to the .drl file
> - Execute DroolsTest
> rule "AccumulateTest"
> 	no-loop true
> 	when
> 		$d: Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( total += $status ),
>                               result( total )
>                          )
> 	then
> 		System.out.println( "ok" ); 
> 		
> end
> Exception is:
> org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=AccumulateTest, agendaGroup=MAIN, salience=0, no-loop=true]
> 	com/sample/Rule_AccumulateTest_0.java (27:834) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (27:869) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : Syntax error, insert ";" to complete Statement
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : $status cannot be resolved
> 	com/sample/Rule_AccumulateTest_0.java (39:1483) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (39:1518) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:64)
> 	at com.sample.DroolsTest.main(DroolsTest.java:21)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:52:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 08:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-487) Rewrite Retransmitter
In-Reply-To: <24146495.1177407030465.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19360260.1187614321743.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-487.
---------------------------

    Resolution: Done

Much simpler (= maintainable) code now and same or even slightly better performance

> Rewrite Retransmitter
> ---------------------
>
>                 Key: JGRP-487
>                 URL: http://jira.jboss.com/jira/browse/JGRP-487
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: Retransmitter.java
>
>
> The old Retransmitter is (a) too complex and (b) uses a linear list of Entries as retransmission list, which has a cost proportional to the number of messages in the retransmit buffer.
> We should switch to using simple scheduled futures with the TimeScheduler for retransmissions and cancel the futures when a message has been acked.
> The new Retransmitter.java is 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 lists.jboss.org  Mon Aug 20 08:52:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 20 Aug 2007 08:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
In-Reply-To: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26024741.1187614322176.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf updated EJBTHREE-1031:
------------------------------------

    Fix Version/s: AS 4.2.2.GA
                   EJB 3.0 RC11 - FD

> runaway SLSB instance creation with ThreadLocalPool
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1031
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:54:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 20 Aug 2007 08:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
In-Reply-To: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30260272.1187614441101.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1031?page=comments#action_12372920 ] 
            
Carlo de Wolf commented on EJBTHREE-1031:
-----------------------------------------

Rev 64706: Fix for AS 4.2: Thread local pool is now backed by infinite pool to handle the life cycle of beans.

> runaway SLSB instance creation with ThreadLocalPool
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1031
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 09:03:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-461) Add
 highest_deliverable to NakreceiverWindow
In-Reply-To: <31148843.1175838778457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31956164.1187614981123.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-461.
---------------------------

    Resolution: Rejected

Not worth the additional complexity, and most likely no gains in performance

> Add highest_deliverable to NakreceiverWindow
> --------------------------------------------
>
>                 Key: JGRP-461
>                 URL: http://jira.jboss.com/jira/browse/JGRP-461
>             Project: JGroups
>          Issue Type: Sub-task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> Currently, we use highest_delivered (= removed) seqno, highest_deliverable would purge more messages faster, if we have a slow receiver (slow to call 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 lists.jboss.org  Mon Aug 20 09:03:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-281) NAKACK: merge
 sent_msgs, received_msgs and delivered_msgs into xmit_table
In-Reply-To: <5139686.1156505087158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22955514.1187614981272.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban closed JGRP-281.
-------------------------


> NAKACK: merge sent_msgs, received_msgs and delivered_msgs into xmit_table
> -------------------------------------------------------------------------
>
>                 Key: JGRP-281
>                 URL: http://jira.jboss.com/jira/browse/JGRP-281
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1, 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> NAKACK buffers sent messages in sent-table and received messages in received-table. We might be able to discard sent-table entirely because received-table will contain a message sent by oneself !
> Once we have loopback in place by default, we can be sure that any message sent by P will be in P's received-table.
> The new design is described in JGroups/doc/design.NAKACK.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 lists.jboss.org  Mon Aug 20 09:05:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-394) Performance
	enhancements
In-Reply-To: <27914397.1166549617965.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5549474.1187615101591.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Checked GroupRequest and RequestCorrelator: they are already optimized

> Performance enhancements
> ------------------------
>
>                 Key: JGRP-394
>                 URL: http://jira.jboss.com/jira/browse/JGRP-394
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> - NAKACK.handleMessage(): NakReceiver.add() --> Retransmitter.add() --> TimeScheduler.add() is quite costly; we also iterate through a linear 
> list when removing a message from the Retransmitter !
> - Bundler: sending is over-synchronized; use ConcurrentHashMap for msgs
> - GroupRequest and RequestCorrelator eat CPU cycles in MessageDispatcher: remove 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 lists.jboss.org  Mon Aug 20 09:11:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-394) Performance
	enhancements
In-Reply-To: <27914397.1166549617965.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16683591.1187615461123.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-394.
---------------------------

    Resolution: Done

Looked at Bundler: we don't need a ConcurrentHashMap as access to msgs is very short and we need to synchronize anyway

> Performance enhancements
> ------------------------
>
>                 Key: JGRP-394
>                 URL: http://jira.jboss.com/jira/browse/JGRP-394
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> - NAKACK.handleMessage(): NakReceiver.add() --> Retransmitter.add() --> TimeScheduler.add() is quite costly; we also iterate through a linear 
> list when removing a message from the Retransmitter !
> - Bundler: sending is over-synchronized; use ConcurrentHashMap for msgs
> - GroupRequest and RequestCorrelator eat CPU cycles in MessageDispatcher: remove 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 lists.jboss.org  Mon Aug 20 10:00:13 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Mon, 20 Aug 2007 10:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2638377.1187618413665.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372937 ] 
            
Jeff Johnson commented on JBPM-1042:
------------------------------------

Hi,
The changes Tom made to GraphElement revision 1.12 included changes to conditionally lock the token in the execute() method look.  I believe those changes solve the problem my test case demonstrates.


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:04:11 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Mon, 20 Aug 2007 10:04:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1592) Backslashes
 not escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10341470.1187618651752.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=comments#action_12372940 ] 
            
Tobias Roth commented on JBPORTAL-1592:
---------------------------------------

No problem about the answering delay, it's not like you have an SLA with me :-)

I admit the problem is getting a bit confusing, I had to look through the whole forum post again myself. On top of that, I had a weird bug and couldn't start my portal anymore. I tried everything to find the cause of the problem, and then, just because I ran out of ideas, I reinstalled my jdk, and things worked again. D'oh.

Anyway, I'll try to explain my problem in different words (I'll also attach example files). I am using your ldif, the one with the jdukes you posted in the forum thread. I made a small modification: I removed the backslash and comma for jduke4, so I have a user to check if everything works without a comma.

Now, there are several jdukes, all of them with a comma in their name except my control user, jduke4. All of them are member of the "User" group.

I have this userSearchFilter: (&((uid={0})(objectClass=person)))
And this roleSearchFilter: (&((member={1})(objectClass=groupOfNames)))

With these filters, all jdukes can log in, but roles are only found for jduke4 (who has no comma in his DN), not for the other jdukes (who all have commas). Escaping the comma with three backslashes in the roleSearchFilter is all very well, but I cannot do that, because I want a filter that finds all jdukes, not just a specific one. It is that part of the jboss portal code that substitutes the {1} from the roleSearchFilter with does not properly escape commas, in my opinion.

I hope I could make this a bit more clear, it is indeed difficult to explain.

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 10:06:01 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Mon, 20 Aug 2007 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6819283.1187618761469.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tobias Roth updated JBPORTAL-1592:
----------------------------------

    Attachment: demo.ldif

ldif with demonstrates the issue (just like in the forum post, but with jduke4 comma removed)

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 10:06:01 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Mon, 20 Aug 2007 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13605367.1187618761826.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tobias Roth updated JBPORTAL-1592:
----------------------------------

    Attachment: ldap_identity-config.xml

ldap configuration to show problem

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 10:41:02 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Mon, 20 Aug 2007 10:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26990602.1187620862699.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372946 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

Sorry... I didn't read carefully enough, specifically:

    boolean actionMustBeLocked = (executionContext.getEvent()!=null)
                                 && (!token.isLocked());
                                        ^^^^^^^^^^^^^^^^^^^^

Yes, that looks like it would cure THIS problem.

I could be dreaming, but it seems like this might also mask real token-control "fights" on a thread that previously would have been detected by the lock.  I'm not sure the lock does anything at all now.  But I must admit that I don't understand what "fights" the lock was intended to detect in the first place.  It's clearly intra-thread, not inter-thread.  

FWIW, IMO, a better fix would be to get rid of the recursion.


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:43:03 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 10:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1092) Invalid Java code
 generated from 'accumulate' function with nested classes
In-Reply-To: <22762348.1187266681169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26415894.1187620983639.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1092.
----------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

Problem was that Class.getName() method returns the binary name of the class and Class.getCanonicalName() is a java 1.5 method. 
Implemented a helper function to generate the canonical name for 1.4 classes.

Unit test and integration tests added.

Thanks for reporting and providing test case.


> Invalid Java code generated from 'accumulate' function with nested classes
> --------------------------------------------------------------------------
>
>                 Key: JBRULES-1092
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1092
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Steps to reproduce:
> - Create a sample new project with the Eclipse plugin
> - Add following rule to the .drl file
> - Execute DroolsTest
> rule "AccumulateTest"
> 	no-loop true
> 	when
> 		$d: Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( total += $status ),
>                               result( total )
>                          )
> 	then
> 		System.out.println( "ok" ); 
> 		
> end
> Exception is:
> org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=AccumulateTest, agendaGroup=MAIN, salience=0, no-loop=true]
> 	com/sample/Rule_AccumulateTest_0.java (27:834) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (27:869) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : Syntax error, insert ";" to complete Statement
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : $status cannot be resolved
> 	com/sample/Rule_AccumulateTest_0.java (39:1483) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (39:1518) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:64)
> 	at com.sample.DroolsTest.main(DroolsTest.java:21)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:51:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 10:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
In-Reply-To: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8681166.1187621461942.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1070:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Exception with "not in" condition with  (int-values)
> ----------------------------------------------------
>
>                 Key: JBRULES-1070
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> // Bob wears plaid       
> Golfer( name == "Bob", 
>         $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
>         $bobsColor : color == "plaid",
>         color != $fredsColor, color != $joesColor,
>         color != $fredsNeighbourColor )
> yields the following exception
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
> 	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:51:02 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
In-Reply-To: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13208374.1187621462196.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1070.
----------------------------------

    Resolution: Duplicate Issue

This was fixed as part of:

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


> Exception with "not in" condition with  (int-values)
> ----------------------------------------------------
>
>                 Key: JBRULES-1070
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> // Bob wears plaid       
> Golfer( name == "Bob", 
>         $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
>         $bobsColor : color == "plaid",
>         color != $fredsColor, color != $joesColor,
>         color != $fredsNeighbourColor )
> yields the following exception
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
> 	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 11:14:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <633499.1187622841308.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban reopened JGRP-577:
---------------------------

             
[mail by Brian Campbell]
These logs were produced  as follows:

Server A comes up first and stays up the whole time.  B comes up with
the wrong credentials and, the first time, gets the join rejection/auth
failure message from A and throws the SecurityException on its side.  I
ctrl-c kill B.  Then start B again and it falls into the join timeout
loop.  Ctrl-C will no longer stop the process so I have to kill -9 it.
Finally I start B one more time - this time with the correct credentials
and it ends up in a similar join timeout loop.   

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>         Attachments: a.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Mon Aug 20 11:14:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15486192.1187622841442.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-577:
--------------------------

    Attachment: a.log

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>         Attachments: a.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Mon Aug 20 11:16:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18785943.1187622961196.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-577:
--------------------------

    Attachment: b.log

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>         Attachments: a.log, b.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Mon Aug 20 12:43:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 12:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
In-Reply-To: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26018802.1187628181297.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1058:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> nested accessors with Sets - "not contains" is not a valid operator for MVEL
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-1058
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark McNally
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Following does not work:
> 		rule StateMatch
> 			when
> 			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
> 			then 	
> 				retract( $ca );
> 		end
> 		
> 		
> 		public class CandidateAssociation {
> 			private PatientDetails patientDetails;
> 			private NurseDetails   nurseDetails;
> 			private int overlapHours;
> 		
> 			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
> 				super();
> 				this.patientDetails = patientDetails;
> 				this.nurseDetails = nurseDetails;
> 				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
> 			}
> 		    [...]
> 		}
> 		
> 		public class NurseDetails {
> 			private Set stateLicensures = new HashSet();
> 			[...]
> 		}
> 		public class PatientDetails {
> 			private String state;
> 			[...]
> 		}
> Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 
> Also Noticed that the following workaround did not work:
> 		rule State
> 		    dialect "mvel"
> 			when
> 		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
> 			then 	
> 		  	    retract( $ca );
> 		end
> 		
> 		This produced this Exception:
> 		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
> 	        at org.drools.rule.Package.checkValidity(Package.java:408)
> 	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	        at [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 13:02:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 13:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1083) Brackets are
 not always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <396606.1187629321231.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1083?page=comments#action_12372969 ] 
            
Edson Tirelli commented on JBRULES-1083:
----------------------------------------

I think for this case we should fix documentation only and keep parser behavior as it is right now, i.e., for "not" and "exists", the brackets are option only if they are followed by a single pattern. 

The current grammar rules are:

LHS_NOT::= 'not' ( '(' <conditional_element> ')' ) | <pattern>
LHS_EXISTS::= 'exists' ( '(' <conditional_element> ')' ) | <pattern>

So, the following is valid:

not Bus()
not ( Bus() )  // brackets are optional for single pattern.

Any other following conditional element will require the brackets. Following are all valid:

not( Bus() and Driver() )
not( Bus() from $buses )
not( Bus() and not Driver() )
not( Bus() and not( Driver() ) )

Please note that the following is valid and require the ():

not( exists( Bus() ) )

But the above is Semantically EQUIVALENT as:

not( Bus() )



> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 13:11:12 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 13:11:12 -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: <16979760.1187629872791.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 GA
                       (was: jBPM BPEL 1.2 GA)

Upon deployment, the web service module finds the latest version of the process definition *at that time*. Picking up the latest version of the process definition is not generally possible because the WSDL interfaces might have changed. The WSEE specification assumes the WSDL description to be immutable; therefore, no API exists to modify it at runtime. The safe, clean path to pick up the newly deployed version of the process definition is to redeploy the web service module as well.

> 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 GA
>
>
> 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 lists.jboss.org  Mon Aug 20 13:13:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 13:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (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: <26015203.1187629981197.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-200?page=all ]

Alejandro Guizar resolved BPEL-200.
-----------------------------------

    Resolution: Done

SOLUTION Redeploy the web module along with the process archive.

> 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 GA
>
>
> 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 lists.jboss.org  Mon Aug 20 14:00:01 2007
From: jira-events at lists.jboss.org (Anders Persson (JIRA))
Date: Mon, 20 Aug 2007 14:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
Message-ID: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>

It is possible to create a deadlock when trying to close a channel which is not yet connected
---------------------------------------------------------------------------------------------

                 Key: JGRP-578
                 URL: http://jira.jboss.com/jira/browse/JGRP-578
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
         Environment: Windows XP; java 1_5_0_12
            Reporter: Anders Persson
         Assigned To: Bela Ban


The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.

Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Mon Aug 20 14:04:01 2007
From: jira-events at lists.jboss.org (Michael Ihde (JIRA))
Date: Mon, 20 Aug 2007 14:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-923) Creating
 queue/topic with
 JNDI subcontexts fails, e.g. names such as queue/foo/bar
In-Reply-To: <16664219.1173999154492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18621300.1187633041693.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-923?page=comments#action_12372977 ] 
            
Michael Ihde commented on JBMESSAGING-923:
------------------------------------------

What is the status on this, are there plans to fix it?

> Creating queue/topic with JNDI subcontexts fails, e.g. names such as queue/foo/bar
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-923
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-923
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Elias Ross
>
> The following service.xml will generate an exception:
> <server>
>    <loader-repository>
>         jboss.messaging:loader=ScopedLoaderRepository
>         <loader-repository-config>
>                 java2ParentDelegation=false
>         </loader-repository-config>
>    </loader-repository>
>    <mbean code="org.jboss.jms.server.destination.QueueService"
>         name="jboss.messaging.destination:service=Queue,name=ppm/mt"
>         xmbean-dd="xmdesc/Queue-xmbean.xml">
>         <depends optional-attribute-name="ServerPeer">jboss.messaging:service=Se
> rverPeer</depends>
>       <depends>jboss.messaging:service=PostOffice</depends>
>    </mbean>
> </server>
> 15:46:12,205 ERROR [ExceptionUtil] Queue[/queue/ppm/bridge/mqube, name=ppm/bridg
> e/mqube] startService
> javax.naming.NameNotFoundException: ppm 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.rebind(NamingServer.java:165)
>         at org.jnp.server.NamingServer.rebind(NamingServer.java:168)
>         at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:510)
>         at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:477)
>         at org.jboss.jms.server.DestinationJNDIMapper.registerDestination(Destin
> ationJNDIMapper.java:146)
>         at org.jboss.jms.server.destination.QueueService.startService(QueueServi
> ce.java:142)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 16:01:43 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 16:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11549110.1187640103869.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer closed JBRULES-1054.
-----------------------------------

    Resolution: Out of Date

It's already fixed for 4.0.1

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Mon Aug 20 16:01:44 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 16:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1028) importing
 .brxml into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18866195.1187640104174.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=comments#action_12373005 ] 
            
Fernando Meyer commented on JBRULES-1028:
-----------------------------------------

Michael, Should I move the brl and rulemodel to compiler? I think thats the only way to do for drools-ant don't depends from brms.

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Mon Aug 20 16:20:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 16:20:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-216) eclipse bpel designer
	integration
In-Reply-To: <14006792.1166405259742.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15849142.1187641219052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-216?page=all ]

Alejandro Guizar updated BPEL-216:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1 GA
                       (was: jBPM BPEL 1.2 GA)

> eclipse bpel designer integration
> ---------------------------------
>
>                 Key: BPEL-216
>                 URL: http://jira.jboss.com/jira/browse/BPEL-216
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> Enable one-step deployment of a bpel process + interface wsdl definitions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 16:20:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 16:20:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-190) webservice
 descriptors generation tool
Message-ID: <9703418.1187641219643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-190?page=all ]

Alejandro Guizar updated BPEL-190:
----------------------------------

        Fix Version/s: jBPM BPEL 1.1 GA
                           (was: jBPM BPEL 1.2 GA)
    Affects Version/s:     (was: jBPM BPEL 1.1 beta 1)

> webservice descriptors 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
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> 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 lists.jboss.org  Mon Aug 20 16:22:22 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 20 Aug 2007 16:22:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-398) NullPointer when
	weaving a jar
Message-ID: <29684794.1187641342482.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointer when weaving a jar
------------------------------

                 Key: JBBUILD-398
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-398
             Project: JBoss Build System
          Issue Type: Bug
          Components: JBossRetro
            Reporter: Paul Gier
         Assigned To: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


When weaving a jar file, a null pointer exception is thrown if the outputDirectory parameter is null.  The weaver should be able to use the outputJar path.
As a workaround, both the outputDirectory and outputJar parameters should be set to the jar path when weaving a jar 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 lists.jboss.org  Mon Aug 20 16:26:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 20 Aug 2007 16:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-398) NullPointer when
	weaving a jar
In-Reply-To: <29684794.1187641342482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22412028.1187641578236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-398?page=all ]

Paul Gier closed JBBUILD-398.
-----------------------------

    Resolution: Done

> NullPointer when weaving a jar
> ------------------------------
>
>                 Key: JBBUILD-398
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-398
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: JBossRetro
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: JBossRetro-1.1.3.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> When weaving a jar file, a null pointer exception is thrown if the outputDirectory parameter is null.  The weaver should be able to use the outputJar path.
> As a workaround, both the outputDirectory and outputJar parameters should be set to the jar path when weaving a jar 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 lists.jboss.org  Mon Aug 20 17:09:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 17:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-276) generate bpel
 application descriptor along with wsdl service description
Message-ID: <23516822.1187644158226.JavaMail.jira@cloud.prod.atl2.jboss.com>

generate bpel application descriptor along with wsdl service description
------------------------------------------------------------------------

                 Key: BPEL-276
                 URL: http://jira.jboss.com/jira/browse/BPEL-276
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Engine
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.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 lists.jboss.org  Mon Aug 20 17:11:19 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1592) Backslashes
 not escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14406742.1187644279099.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=comments#action_12373013 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1592:
-----------------------------------------------

Ok, few things here:

1) Your configuration was wrong
 - {1} does nothing. Only {0} is valid for roleSearchFilter
 - instead of '(&((member={1})(objectClass=groupOfNames))) ' it should be '(&((cn={0})(objectClass=groupOfNames)))'

Simply you are mixing two things here. RoleModule is responsible only for resolving roles and not user/role relationship. For this you should use proper MembershipModule (LDAPStaticGroupMembershipModuleImpl or LDAPStaticRoleMembershipModuleImpl) and correct 'membershipAttributeID' and 'membershipAttributeIsDN' (see in doc or look into standardidentity-config.xml file). Its all in the docs

2) Still... the issue you described was present, and the solution you proposed was quite a good one :) I was just missing proper use case to make valid test case. Currently uid  'jduke4, Duke' is part of testsuite. I also tested manualy with attached ldif.

Thanks!




> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 17:15:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22162184.1187644518924.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boleslaw Dawidowicz resolved JBPORTAL-1592.
-------------------------------------------

    Resolution: Done

fixed. commited to JBoss_Portal_Branch_2_6.

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 17:21:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1561) google widget
 preferences cannot be updated after window creation
In-Reply-To: <25873473.1184018208231.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5007459.1187644878776.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boleslaw Dawidowicz updated JBPORTAL-1561:
------------------------------------------

    Fix Version/s: 2.6.3 Final
                       (was: 2.6.2 Final)
         Priority: Minor  (was: Major)

this can wait 

> google widget preferences cannot be updated after window creation
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-1561
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1561
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>    Affects Versions: 2.6.1 Final, 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.3 Final
>
>
> 1) add a google widget window to the page
> 2) go to AdminPortlet, navigate and click on the portlet window you added
> 3) there is edit window with widget preferences 
> 4) changing values and hitting 'update' does nothing

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 17:25:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1640) provide OpenSSO
	integration
Message-ID: <21988026.1187645118595.JavaMail.jira@cloud.prod.atl2.jboss.com>

provide OpenSSO integration
---------------------------

                 Key: JBPORTAL-1640
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1640
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.2 Final, 2.8 Final


Provide integration with OpenSSO using tomcat valve mechanism

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 17:40:51 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 17:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
In-Reply-To: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4327739.1187646051475.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-578:
--------------------------

    Fix Version/s: 2.6

> It is possible to create a deadlock when trying to close a channel which is not yet connected
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-578
>                 URL: http://jira.jboss.com/jira/browse/JGRP-578
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1_5_0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.
> Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Mon Aug 20 19:05:18 2007
From: jira-events at lists.jboss.org (Anh Vuong (JIRA))
Date: Mon, 20 Aug 2007 19:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3828433.1187651118705.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1086?page=comments#action_12373031 ] 
            
Anh Vuong commented on JBRULES-1086:
------------------------------------

if custom classs loader does not call definePackage, then Class.getPackage() may return null. Is it possible to put the following code in the place of the commented line:
 
//String pkgName = (pkg != null) ? pkg.getName() : "";

String pkgName = "";
if (pkg == null) {
    int index = clazz.getName().lastIndexOf('.');
    if (index != -1)
        pkgName = clazz.getName().substring(0, index);
}
else 
    pkgName = pkg.getName();


> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 19:38:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 20 Aug 2007 19:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-821) ValueList in rule
	model
In-Reply-To: <19103957.1177544080454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24404213.1187653098347.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale updated JBRULES-821:
----------------------------------

          Component/s: drools-brms
        Fix Version/s: 4.0.1
    Affects Version/s:  4.0.0.GA

> ValueList in rule model
> -----------------------
>
>                 Key: JBRULES-821
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-821
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>         Attachments: jbrmsDropDown.doc
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 20:50:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1089) Getting "could
 not access property ('=')" for a valid rule.
In-Reply-To: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24117729.1187657418691.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1089:
----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Getting "could not access property ('=')" for a valid rule.
> -----------------------------------------------------------
>
>                 Key: JBRULES-1089
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
>            Reporter: Arsalan Zaidi
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
> Sent: 13 August 2007 22:16
> To: Rules Users List
> Subject: Re: [rules-users] could not access property ('=')
> Attachments: ATT426765.txt
>    This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?
>    Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 
> when
>            $dto : DTO( )
>            W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1
> then
>    Thanks, and hope it helps.
>    Edson
> 2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
>   Hi.
>   I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.
>   I have a rule which looks like this:
>   rule "W250.42 Editable"
>         when
>               DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )
>         then
>               System.out.println ("0" );
>               Action action = createAction("W250.42" , false , true );
>               retList.add(action); 
>   end 
>   both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .
>   Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.
>   org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )
>         at org.drools.reteoo.Rete.assertObject(Rete.java:168 )
>         at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 
>         at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )
>         at com.sample.DroolsTest.main( DroolsTest.java:34)
>   Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )
>         at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )
>         at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )
>         at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)
>         at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 
>         at org.mvel.MVEL.executeExpression( MVEL.java:202)
>         at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )
>         ... 10 more
>   Caused by: org.mvel.PropertyAccessException: could not access property ('=') 
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )
>         ... 18 more
>   If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.
>   I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')
>   What seems to be the issue?
>   Thanks in advance!
>   Regards,
>   --Arsalan
>         This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 
>        
>   _______________________________________________
>   rules-users mailing list
>   rules-users at lists.jboss.org 
>   https://lists.jboss.org/mailman/listinfo/rules-users
> -- 
>   Edson Tirelli
>   Software Engineer - JBoss Rules Core Developer
>   Office: +55 11 3529-6000
>   Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat @ www.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 lists.jboss.org  Mon Aug 20 20:50:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2098042.1187657418888.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1091:
----------------------------------

    Fix Version/s: 4.0.1

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Mon Aug 20 20:50:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1102) Bug in
 DefaultBetaConstraint class indexing to never turn on
In-Reply-To: <22237245.1187501761200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27672389.1187657419045.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1102:
----------------------------------

    Fix Version/s: 4.0.1

> Bug in DefaultBetaConstraint class indexing to never turn on
> ------------------------------------------------------------
>
>                 Key: JBRULES-1102
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1102
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Look at line 75 of DefaultBetaConstraint: notice the (depth <= this.indexed). This will always evaluate to false. It should be this.indexed < depth
> This bug and the one reported here (http://jira.jboss.com/jira/browse/JBRULES-1101) make sure that indexing is not used 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 lists.jboss.org  Mon Aug 20 20:50:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10568278.1187657419232.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1101:
----------------------------------

    Fix Version/s: 4.0.1

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 20:52:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1102) Bug in
 DefaultBetaConstraint class indexing to never turn on
In-Reply-To: <22237245.1187501761200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8574688.1187657538292.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1102.
---------------------------------

    Resolution: Done

This is fixed, please use the latest snapshot, as there is more wrong with this class than just the depth check you noticed.

> Bug in DefaultBetaConstraint class indexing to never turn on
> ------------------------------------------------------------
>
>                 Key: JBRULES-1102
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1102
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Look at line 75 of DefaultBetaConstraint: notice the (depth <= this.indexed). This will always evaluate to false. It should be this.indexed < depth
> This bug and the one reported here (http://jira.jboss.com/jira/browse/JBRULES-1101) make sure that indexing is not used 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 lists.jboss.org  Mon Aug 20 22:23:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 22:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15503991.1187662998502.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer reassigned JBRULES-1053:
---------------------------------------

    Assignee: Fernando Meyer  (was: Edson Tirelli)

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 23:00:50 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 23:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29554333.1187665250406.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer closed JBRULES-1053.
-----------------------------------

    Resolution: Won't Fix

Hi Eric, after some tests I noticed that in java language you can't import the same class name twice even if the class is defined in different packages, ie try creating a java file and import both import java.awt.List; import java.util.List; It won't work, you will get a similar error from javac compiler

So you can try using two package builders as I did in the following example 

    public void testImportColision () throws Exception  { 
        final PackageBuilder builder = new PackageBuilder();
        final PackageBuilder builder2 = new PackageBuilder();
        builder.addPackageFromDrl( new InputStreamReader( getClass().getResourceAsStream( "nested1.drl" ) ) );
        builder2.addPackageFromDrl( new InputStreamReader( getClass().getResourceAsStream( "nested2.drl" ) ) );
        final Package pkg = builder.getPackage();
        final Package pkg2 = builder2.getPackage();
 
        final RuleBase ruleBase = getRuleBase();
        ruleBase.addPackage( pkg );
        ruleBase.addPackage( pkg2 );
 
 
        final WorkingMemory workingMemory = ruleBase.newStatefulSession();
 
        workingMemory.insert( new FirstClass() );
        workingMemory.insert( new SecondClass() );
        workingMemory.insert( new FirstClass.AlternativeKey() );
        workingMemory.insert( new SecondClass.AlternativeKey() );
 
        workingMemory.fireAllRules();
    }

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 00:14:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Aug 2007 00:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1038) Client side
 failover hopping does not work
In-Reply-To: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6280517.1187669658304.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBMESSAGING-1038:
-----------------------------------------

    Affects Version/s: 1.4.0.CR1

> Client side failover hopping does not work
> ------------------------------------------
>
>                 Key: JBMESSAGING-1038
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.
> if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".
> Instead it should iterate through the list of delegates trying each one in turn.
> Need to write a test for this 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 lists.jboss.org  Tue Aug 21 00:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Aug 2007 00:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5422455.1187670258397.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1027?page=comments#action_12373049 ] 
            
Clebert Suconic commented on JBMESSAGING-1027:
----------------------------------------------

Update: There is one test I still have to write for this client... validating when a client is killed.

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 01:59:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 01:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1090) Simple data field
	enums in BRMS
In-Reply-To: <21981533.1187257381183.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30353098.1187675958400.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-1090.
----------------------------------

    Resolution: Done

> Simple data field enums in BRMS
> -------------------------------
>
>                 Key: JBRULES-1090
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1090
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Can use MVEL (or something) to store (as a discrete asset) a mapping of fact/fields to value lists. Then these value lists can be used in the Guided editor. 
> eg:
> Person.age : [1, 2, 3, 4, 5, 6, 7]
> Person.sex: [M, F]
> Person.classification: [ HIGH, LOW]
> these are then used to drive drop downs. 
> For extra bonus points, provide a means to display a different value to what is rendered. 
> This can then be loaded as a separate map into SCE and loaded up to the client for display as 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 lists.jboss.org  Tue Aug 21 01:59:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 01:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-821) ValueList in rule
	model
In-Reply-To: <19103957.1177544080454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19254068.1187675958577.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-821.
---------------------------------

    Resolution: Done

> ValueList in rule model
> -----------------------
>
>                 Key: JBRULES-821
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-821
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>         Attachments: jbrmsDropDown.doc
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 03:39:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 03:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22495141.1187681958552.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12373057 ] 
            
Michael Neale commented on JBRULES-1060:
----------------------------------------

yes I can run this to completion if I give it -Xmx500M (not sure what else will work, I just tried it):

Something is up
Run time (milliseconds): 21100
Finished problem at Tue Aug 21 17:41:11 EST 2007

This is a combination explosion, but it certainly works. In my case, I didn't see an OOME reported as well (on Linux, Fedora 7, JSE5). I will try on the mac as well, but it seems in some cases OOME is being swallowed somehow before it is being reported. Perhaps command line it wil show it (I was running it from within eclipse).

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Tue Aug 21 03:49:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 03:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22629492.1187682558372.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12373061 ] 
            
Michael Neale commented on JBRULES-1060:
----------------------------------------

Yes I have checked the code, there is nowhere we catch Throwable that may be the cause of this non reporting of OOME that I can see. 

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Tue Aug 21 04:16:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 04:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-579) New property:
	bind_interface
Message-ID: <28281953.1187684178395.JavaMail.jira@cloud.prod.atl2.jboss.com>

New property: bind_interface
----------------------------

                 Key: JGRP-579
                 URL: http://jira.jboss.com/jira/browse/JGRP-579
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


bind_addr tells JGroups which interface to bind to. However, if an IP address has more than 1 interface, e.g. in the case of IP Bonding, the JDK simply picks the first interface.
Similarly, if a given interface has more than 1 associated InetAddress, we simply pick the first.

Adding a property bind_interface (-Djgroups.bind_interface) allows us to exactly pick the correct network interface in both cases above.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:08:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 05:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-579) New property:
	bind_interface
In-Reply-To: <28281953.1187684178395.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14992167.1187687298243.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-579.
---------------------------

    Resolution: Done

> New property: bind_interface
> ----------------------------
>
>                 Key: JGRP-579
>                 URL: http://jira.jboss.com/jira/browse/JGRP-579
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> bind_addr tells JGroups which interface to bind to. However, if an IP address has more than 1 interface, e.g. in the case of IP Bonding, the JDK simply picks the first interface.
> Similarly, if a given interface has more than 1 associated InetAddress, we simply pick the first.
> Adding a property bind_interface (-Djgroups.bind_interface) allows us to exactly pick the correct network interface in both cases above.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:25:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3415) Port RARDeployer
In-Reply-To: <11713167.1153692311447.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28823824.1187688318379.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-3415:
-------------------------------------

    Assignee:     (was: Weston Price)
    Priority: Critical  (was: Major)

> Port RARDeployer
> ----------------
>
>                 Key: JBAS-3415
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3415
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Deployment services
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The RARDeployer needs to be ported or rewritten for the new VDF

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:25:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3412) Port ClientDeployer
 and complete JavaEE5 support
In-Reply-To: <30460334.1153691831496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1358255.1187688318600.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-3412:
-------------------------------------

    Priority: Critical  (was: Major)

> Port ClientDeployer and complete JavaEE5 support
> ------------------------------------------------
>
>                 Key: JBAS-3412
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3412
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The ClientDeployer needs to be ported to the new VDF and the JavaEE 5 changes 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 lists.jboss.org  Tue Aug 21 05:41:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 21 Aug 2007 05:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-218) make the imported
 wsdl documents a source of partner service descriptions
In-Reply-To: <17113795.1166408025580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33352088.1187689278525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-218?page=all ]

Alejandro Guizar updated BPEL-218:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1 GA
                       (was: jBPM BPEL 1.2 GA)

> make the imported wsdl documents a source of partner service descriptions
> -------------------------------------------------------------------------
>
>                 Key: BPEL-218
>                 URL: http://jira.jboss.com/jira/browse/BPEL-218
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:52:19 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3766) Port the webservice
	deployer
In-Reply-To: <28538797.1160804141717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9311207.1187689939836.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-3766:
-------------------------------------

    Priority: Critical  (was: Major)

> Port the webservice deployer
> ----------------------------
>
>                 Key: JBAS-3766
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3766
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>         Assigned To: Thomas Diesler
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The old jmx/interceptor based jbossws deployer is now complete broken:
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.ws:service=DeployerInterceptorEJB21
>  -> jboss.ejb:service=EJBDeployer{Create:** NOT FOUND **}
>  -> jboss.ejb:service=EJBDeployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorEJB3
>  -> jboss.ejb3:service=EJB3Deployer{Create:** NOT FOUND **}
>  -> jboss.ejb3:service=EJB3Deployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorNestedJSE
>  -> jboss.ws:service=WebServiceDeployerJSE{Start:Configured}
>  -> jboss.ws:service=WebServiceDeployerJSE{Create:Configured}
> jboss.ws:service=WebServiceDeployerJSE
>  -> jboss.web:service=WebServer{Start:** NOT FOUND **}
>  -> jboss.web:service=WebServer{Create:** NOT FOUND **}
> *** CONTEXTS IN ERROR: Name -> Error
> jboss.web:service=WebServer -> ** NOT FOUND **
> jboss.ejb3:service=EJB3Deployer -> ** NOT FOUND **
> jboss.ejb:service=EJBDeployer -> ** NOT FOUND **
> It needs to be ported to a deployer that augments the metadata passed to other deployers. This means no unapckaing of wars to modify the war 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 lists.jboss.org  Tue Aug 21 05:54:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3768) Define initial
 persistent format of the profile repository
In-Reply-To: <6622737.1160958581689.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4541043.1187690058230.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-3768:
-------------------------------------

    Priority: Critical  (was: Major)

> Define initial persistent format of the profile repository
> ----------------------------------------------------------
>
>                 Key: JBAS-3768
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3768
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> We need to define the initial profile repository format with consideration of future migrations, jsr88, admin tools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:08:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3766) Port the webservice
	deployer
In-Reply-To: <28538797.1160804141717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17110736.1187690898353.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-3766.
----------------------------------

    Resolution: Done

Resolved with jbossws-2.0.1

> Port the webservice deployer
> ----------------------------
>
>                 Key: JBAS-3766
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3766
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>         Assigned To: Thomas Diesler
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The old jmx/interceptor based jbossws deployer is now complete broken:
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.ws:service=DeployerInterceptorEJB21
>  -> jboss.ejb:service=EJBDeployer{Create:** NOT FOUND **}
>  -> jboss.ejb:service=EJBDeployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorEJB3
>  -> jboss.ejb3:service=EJB3Deployer{Create:** NOT FOUND **}
>  -> jboss.ejb3:service=EJB3Deployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorNestedJSE
>  -> jboss.ws:service=WebServiceDeployerJSE{Start:Configured}
>  -> jboss.ws:service=WebServiceDeployerJSE{Create:Configured}
> jboss.ws:service=WebServiceDeployerJSE
>  -> jboss.web:service=WebServer{Start:** NOT FOUND **}
>  -> jboss.web:service=WebServer{Create:** NOT FOUND **}
> *** CONTEXTS IN ERROR: Name -> Error
> jboss.web:service=WebServer -> ** NOT FOUND **
> jboss.ejb3:service=EJB3Deployer -> ** NOT FOUND **
> jboss.ejb:service=EJBDeployer -> ** NOT FOUND **
> It needs to be ported to a deployer that augments the metadata passed to other deployers. This means no unapckaing of wars to modify the war 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 lists.jboss.org  Tue Aug 21 06:14:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4898924.1187691258259.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4562:
-------------------------------------

    Priority: Critical  (was: Major)

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:18:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4832600.1187691509198.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Priority: Critical  (was: Major)

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:18:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17829096.1187691509397.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:18:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4564) Hibernate
	EntityManager 3.3.2
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8557370.1187691509575.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4564:
-------------------------------------

      Component/s: Hibernate service
    Fix Version/s:  JBossAS-5.0.0.Beta3
         Priority: Critical  (was: Major)

> Hibernate EntityManager 3.3.2
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:35:35 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:35:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4565) Resolve the issue
 of Hibernate Validator
In-Reply-To: <16152273.1184779067941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30719129.1187692535930.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Link to Validator: http://www.hibernate.org/412.html

> Resolve the issue of Hibernate Validator
> ----------------------------------------
>
>                 Key: JBAS-4565
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4565
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Emmanuel Bernard
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:37:18 2007
From: jira-events at lists.jboss.org (Shahad Ahmed (JIRA))
Date: Tue, 21 Aug 2007 06:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
Message-ID: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>

Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
----------------------------------------------------------------------------------------------

                 Key: JBRULES-1106
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Windows XP SP2, Sun JRE 1.5_09
            Reporter: Shahad Ahmed
         Assigned To: Mark Proctor


I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.

Here's how to replicate the problem for a clean BRMS install:

1. Create a new category called test.

2. In the defaultPackage create a new DSL called test as shown below:

[when]true=eval(true)
[then]report=System.out.println("Hello");

3. Save the test DSL

4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.

5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".

6. Save rule test1.

7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.

8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).

9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.

10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).

package defaultPackage

rule "test1"
	dialect "java"
	when
	eval(true)
	then
	System.out.println("Hello");
end

rule "test1"
	dialect "java"
	when
	eval(true)
	then
	System.out.println("Hello");
end

Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:40:28 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:40:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3277) Webservices tests
 deployment exceptions in jboss-head testsuite
Message-ID: <23871124.1187692828863.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-3277.
----------------------------------

    Fix Version/s:     (was:  JBossAS-5.0.0.Beta3)
       Resolution: Cannot Reproduce Bug

Cannot reproduce with jbossws-2.0.1.GA

tests-webservice:
    [junit] Running org.jboss.test.webservice.admindevel.ExampleTestCase
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 19.304 sec
    [junit] Running org.jboss.test.webservice.admindevel.ExplodedExampleTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.929 sec
    [junit] Running org.jboss.test.webservice.admindevel.RedeployExampleTestCase
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 8.35 sec


> Webservices tests deployment exceptions in jboss-head testsuite
> ---------------------------------------------------------------
>
>                 Key: JBAS-3277
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3277
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Thomas Diesler
>
> All webservices tests in the jboss-head testsuite are unable to deploy the test resources.
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060531155015/testsuite/output/log/test.log
> The DeplomentException stack trace is given below.
> org.jboss.deployment.DeploymentException: Could not create deployment: file:/services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/output/lib/ws4ee-admindevel.jar; - nested throwable: (java.lang.NoClassDefFoundError: org/jboss/webservice/metadata/jaxrpcmapping/MethodParamPartsMapping)
> 	at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:53)
> 	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:975)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:560)
>         ..................................
> Caused by: java.lang.NoClassDefFoundError: org/jboss/webservice/metadata/jaxrpcmapping/MethodParamPartsMapping
> 	at org.jboss.ws.server.WebServiceDeployerEJB21.createWebServicesMetaData(WebServiceDeployerEJB21.java:110)
> 	at org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:103)
> 	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: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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:40:29 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 06:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-441) TP.loopback might
 cause some issues with incorrectly purged messages in STABLE
In-Reply-To: <31577745.1174304855268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1432257.1187692829171.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-441.
---------------------------

    Resolution: Cannot Reproduce Bug

This was most likely an issue in STABLE (fixed in 2.5) and not with loopback

> TP.loopback might cause some issues with incorrectly purged messages in STABLE
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-441
>                 URL: http://jira.jboss.com/jira/browse/JGRP-441
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Investigate, I've seen this a few times, but only when loopback was enabled.
> Workaround is always to leave loopback off (default 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 lists.jboss.org  Tue Aug 21 06:42:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 06:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-155) TP.loopback should
	always be used
Message-ID: <9478559.1187692938352.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-155:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Not sure this is relevant any longer

> TP.loopback should always be used
> ---------------------------------
>
>                 Key: JGRP-155
>                 URL: http://jira.jboss.com/jira/browse/JGRP-155
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9, 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> Investigate the 3 potential problem areas below:
> - Memory leak caused by FC when credits are received too quickly
> - Deadlocks caused by same threads calling themselves (e.g. VIEW_OK ack msgs)
> - Preemption doesn't work: Scheduler is meaningless here

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:42:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3844) "array element type
 mismatch"
 when deserializing JAX-RPC value type properties of array type when size >2
In-Reply-To: <18484945.1163176662202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32549154.1187692939093.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-3844.
----------------------------------

    Resolution: Out of Date

Does this still occur with jbossws-2.0.1.GA?

> "array element type mismatch" when deserializing JAX-RPC value type properties of array type when size >2  
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3844
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3844
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Andrei Iltchenko
>         Assigned To: Thomas Diesler
>
> We experience a problem with the WS4EE stack on JBoss 4.0.3 when deserializing JAX-RPC value type properties of array type when the number of elements is greater than 2 and when the request envelope was created by a .NET client. There are similar issues reported on AXIS. Here's a typical stack trace we get:
> 14:59:13,330 ERROR [BeanPropertyTarget] Could not convert [Lcrm.application.business.common.customersvc.CallDataObject; to bean field 'typedElements[2]', type [Lcrm.application.business.common.customersvc.CallDataObject;
> 14:59:13,390 ERROR [RPCInvocation] java.lang.IllegalArgumentException: array element type mismatch
> java.lang.IllegalArgumentException: array element type mismatch
>       at org.jboss.axis.encoding.ser.BeanPropertyTarget.set(BeanPropertyTarget.java:243)
>       at org.jboss.axis.encoding.DeserializerImpl.valueComplete(DeserializerImpl.java:305)
>       at org.jboss.axis.encoding.DeserializerImpl.endElement(DeserializerImpl.java:590)
>       at org.jboss.axis.encoding.DeserializationContextImpl.endElement(DeserializationContextImpl.java:1269)
>       at org.jboss.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:252)
>       at org.jboss.axis.message.SOAPElementAxisImpl.publishToHandler(SOAPElementAxisImpl.java:1394)
>       at org.jboss.axis.message.RPCElement.deserialize(RPCElement.java:266)
>       at org.jboss.axis.message.RPCElement.getParams(RPCElement.java:402)
>       at org.jboss.axis.providers.java.RPCInvocation.prepareFromRequestEnvelope(RPCInvocation.java:235)
>       at org.jboss.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:103)
>       at org.jboss.axis.providers.java.JavaProvider.invoke(JavaProvider.java:358)
>       at org.jboss.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:73)
>       at org.jboss.axis.SimpleChain.doVisiting(SimpleChain.java:160)
>       at org.jboss.axis.SimpleChain.invoke(SimpleChain.java:123)
>       at org.jboss.axis.handlers.soap.SOAPService.invoke(SOAPService.java:560)
>       at org.jboss.webservice.server.ServerEngine.invokeInternal(ServerEngine.java:215)
>       at org.jboss.webservice.server.ServerEngine.invoke(ServerEngine.java:104)
>       at org.jboss.axis.transport.http.AxisServlet.doPost(AxisServlet.java:911)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>       at org.jboss.axis.transport.http.AxisServletBase.service(AxisServletBase.java:370)
>       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:524)
>       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)
>  
>  
> Message:
>  
>       <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
>         <soap:Header>
>           <wsa:Action>
>           </wsa:Action>
>           <wsa:MessageID>urn:uuid:6bdec88b-6594-4cae-81a5-628b86b75699</wsa:MessageID>
>           <wsa:ReplyTo>
>             <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
>           </wsa:ReplyTo>
>           <wsa:To>http://localhost:8082/ws/customersvc</wsa:To>
>           <wsse:Security>
>             <wsu:Timestamp wsu:Id="Timestamp-b935bb5d-4a72-4b8d-ba5d-d529e18cc23e">
>               <wsu:Created>2006-11-10T13:59:13Z</wsu:Created>
>               <wsu:Expires>2006-11-10T14:04:13Z</wsu:Expires>
>             </wsu:Timestamp>
>           </wsse:Security>
>         </soap:Header>
>         <soap:Body>
>           <setCustomerDo xmlns="http://logic.business.application.crm">
>             <update xmlns="">
>               <deleted>false</deleted>
>               <created>true</created>
>               <pruned>true</pruned>
>               <Original xsi:nil="true" />
>               <CRC>0</CRC>
>               <customerId>0002</customerId>
>               <contractDate>2006-11-07T00:00:00</contractDate>
>               <call>
>                 <typedElements>
>                   <deleted>false</deleted>
>                   <created>true</created>
>                   <pruned>true</pruned>
>                   <Original xsi:nil="true" />
>                   <CRC>0</CRC>
>                   <callResolved>false</callResolved>
>                   <callDescription xsi:nil="true" />
>                   <callTimestamp>0001-01-01T00:00:00</callTimestamp>
>                 </typedElements>
>                 <typedElements>
>                   <deleted>false</deleted>
>                   <created>true</created>
>                   <pruned>true</pruned>
>                   <Original xsi:nil="true" />
>                   <CRC>0</CRC>
>                   <callResolved>false</callResolved>
>                   <callDescription xsi:nil="true" />
>                   <callTimestamp>0001-01-01T00:00:00</callTimestamp>
>                 </typedElements>
>                 <typedElements>
>                   <deleted>false</deleted>
>                   <created>true</created>
>                   <pruned>true</pruned>
>                   <Original xsi:nil="true" />
>                   <CRC>0</CRC>
>                   <callResolved>false</callResolved>
>                   <callDescription xsi:nil="true" />
>                   <callTimestamp>0001-01-01T00:00:00</callTimestamp>
>                 </typedElements>
>               </call>
>               <firstName>Andre</firstName>
>               <serviceAgreement>
>                 <deleted>false</deleted>
>                 <created>true</created>
>                 <pruned>true</pruned>
>                 <Original xsi:nil="true" />
>                 <CRC>0</CRC>
>                 <serviceLevel>
>                   <value>1</value>
>                 </serviceLevel>
>                 <saDescription>Medium Service</saDescription>
>                 <saPrice>50.95</saPrice>
>                 <customer />
>                 <saId>0001</saId>
>               </serviceAgreement>
>               <customerTitle>Mr</customerTitle>
>               <lastName>Bos</lastName>
>               <address>
>                 <countryCode>31</countryCode>
>                 <phone xsi:nil="true" />
>                 <zipCode>1005 BB</zipCode>
>                 <street>Hoogoorddreef</street>
>                 <city>Amsterdam</city>
>                 <stateCode xsi:nil="true" />
>                 <email>Reinier.Bos at nl.compuware.com</email>
>               </address>
>             </update>
>           </setCustomerDo>
>         </soap:Body>
>       </soap:Envelope>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:44:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:44:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3960) Web Service Test
 case failed in JBoss AS 4.0.5GA
In-Reply-To: <19740846.1166771331635.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18801902.1187693059605.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-3960.
----------------------------------

    Resolution: Out of Date

Fixed with jboss-4.2.1

> Web Service Test case failed in JBoss AS 4.0.5GA
> ------------------------------------------------
>
>                 Key: JBAS-3960
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3960
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Arch: x86_64
> OS:   RHEL4U4
> JVM: Sun jdk version "1.5.0_06"
> JBoss Version: JBoss AS 4.0.5 GA and JBoss AS 4.0.5 GA src 
>            Reporter: Steven lian
>         Assigned To: Thomas Diesler
>
> When running JBoss AS testsuite,the testcase org.jboss.test.webservice.secure.SimpleClientSecureTestCase and  org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase is failed for the exceptions.
> reproduce steps:
> 1.build jboss AS 4.0.5 src and start JBoss server with all configuration
> 2.cd $JBOSS_HOME_SRC/testsuite
> 3.ant onte-test -Dtest=org.jboss.test.webservice.secure.SimpleClientSecureTestCase
> 4.ant onte-test -Dtest=org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase
> Result:
> Buildfile: build.xml
> one-test:
>    [delete] Deleting: /root/jboss-4.0.5.GA-src/testsuite/output/log/test.log
>     [junit] Running org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 3.502 sec
>     [junit] Test org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase FAILED
> one-test:
>    [delete] Deleting: /root/jboss-4.0.5.GA-src/testsuite/output/log/test.log
>     [junit] Running org.jboss.test.webservice.secure.SimpleClientSecureTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 3.934 sec
>     [junit] Test org.jboss.test.webservice.secure.SimpleClientSecureTestCase FAILED
> The test log :
> Testcase: testWithTransportOptions took 1.934 sec
>         Caused an 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(Unknown Source)
>         at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:90)
>         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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:47:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16234348.1187693239019.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler updated JBAS-4567:
---------------------------------

    Summary: Install jbossws-2.0.1.GA  (was: Install jbossws-2.1.0.GA)

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:47:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10971432.1187693239524.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-4567.
----------------------------------

    Resolution: Done

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:47:20 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3671)
 org.jboss.axis.ConfigurationException: No engine configuration file
In-Reply-To: <13187415.1158701761524.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20273960.1187693240138.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-3671.
----------------------------------

    Resolution: Out of Date

Fixed with jbossws in jboss-4.2.x

> 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 lists.jboss.org  Tue Aug 21 06:47:20 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3670)
 org.jboss.axis.ConfigurationException: No engine configuration file
In-Reply-To: <7732126.1158701761366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30517272.1187693240368.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-3670.
----------------------------------

    Resolution: Duplicate Issue

> 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 lists.jboss.org  Tue Aug 21 06:49:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3827) Remove JMS
	transport support
In-Reply-To: <8347223.1162772081450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32260339.1187693358282.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-3827.
----------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
       Resolution: Out of Date

> Remove JMS transport support
> ----------------------------
>
>                 Key: JBAS-3827
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3827
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>
> This should all be handled by jbossws

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 07:13:31 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 07:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
In-Reply-To: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7473986.1187694811692.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-578.
---------------------------

    Resolution: Rejected

Connect() and disconnect() or close() are not supposed to be called from different threads, so the above issue is a bit artificial.
I don't want to move the lock down (e.g. around leaving) as this increases the finite state space and therefore complicates the code.
I intend to remove the disable_initial_coord in 3.0 anyway, so this issue is moot.
Since there is a workaround for cancellation of connect(), your code should continue running fine.

> It is possible to create a deadlock when trying to close a channel which is not yet connected
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-578
>                 URL: http://jira.jboss.com/jira/browse/JGRP-578
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1_5_0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.
> Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Tue Aug 21 07:21:20 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 07:21:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4092) Clean up the
 tests-webservice-ssl target
In-Reply-To: <24737466.1171313430026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33524187.1187695280179.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler resolved JBAS-4092.
----------------------------------

    Resolution: Done

Fixed in trunk and Branch_4_4

> Clean up the tests-webservice-ssl target
> ----------------------------------------
>
>                 Key: JBAS-4092
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4092
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>            Priority: Minor
>             Fix For: JBossAS-4.2.2.GA
>
>
> There is a server.xml file for the tests-webservice-ssl target. However, no tests actually get executed when you run this target. According to build.xml in testsuite, here are the tests it is trying to pull in: 
> <patternset id="webservice-ssl.includes"> 
>     <include name="org/jboss/test/webservice/secure/**/*TestCase.class"/> 
>     <exclude name="org/jboss/test/webservice/secure/noenv/**/*TestCase.class"/> 
>   </patternset> 
> So I guess the tests-webservice-ssl target is obsolete? Can someone from the Web Services team comment?
> (see JBAS-4025)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 07:24:27 2007
From: jira-events at lists.jboss.org (Alexandre Russel (JIRA))
Date: Tue, 21 Aug 2007 07:24:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-11) Memory based
	eviction policy
Message-ID: <5185146.1187695467183.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-11?page=all ]

Alexandre Russel updated JBCACHE-11:
------------------------------------

    Attachment: memoryBaseEviction.txt

Hi,
a patch not meant to be comited but to get things started.
the idea is to separate:
when is there eviction => decided by EvictionTask.
which node is evicted => decided by the algorithm.
how many are evicted => decided by the number of nodes in the cache.

The patch keep the algoritm. It creates an abstract class EvictionTask,
with 2 child EvictionTimerTask (the previous EvictionTask) and 
EvictionMemoryTask (a new EvictionTask based on memory).

I added setter and getter on EvictionPolicyConfig for maxNodes.

The EvictionMemoryTask listen to the memory pool that support usage threshold
and that matches a regexp given in config.
It accept 2 settings, a minimum and a maximum percentage of memory.
When there is a notification that the first minimum of memory is
exceded, the maximum number of nodes is set to half its value.
If it goes over the maximum percentage the maximum number of nodes goes to 1.

I used sun's jvm. If you run the test, you may want to check the number
 of objects put in the list. It was set to be a raisonable value on my
computer.

If you think it is a good way to add memory based eviction, let me know
and I'll improve on it. (Few improvements would be to be able to increment 
max nodes when memory is back to a low value and have more than just 2 values 
max and min)
alex


> Memory based eviction policy
> ----------------------------
>
>                 Key: JBCACHE-11
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-11
>             Project: JBoss Cache
>          Issue Type: Feature Request
>          Components: Eviction
>            Reporter: Bela Ban
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>         Attachments: memoryBaseEviction.txt
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> (maybe only in JDK 1.5, which has
>   triggers for low memory)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 07:41:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 07:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-577) AUTH: join
 rejection won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15436589.1187696478380.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

This was caused by UNICAST which created a Connection for B on the first (failed) JOIN. Subsequent JOINs failed because that connection was not removed on the failed JOIN, so A incorrectly used the old connection.
Fixed in CVS head (2.6) and 2.5.1

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>         Attachments: a.log, b.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Tue Aug 21 07:55:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 07:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12953272.1187697318238.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-577.
---------------------------

    Resolution: Done

done as suggested in comment, tested in CVS head and 2.5 branch

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>         Attachments: a.log, b.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Tue Aug 21 08:44:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 08:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3450) Fix
 org.jboss.test.webservice.jbws309.JBWS309TestCase running under JACC
In-Reply-To: <7324549.1154372651507.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30223221.1187700258563.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Diesler reassigned JBAS-3450:
------------------------------------

    Assignee: Anil Saldhana  (was: Thomas Diesler)

How can I reproduce this?

> Fix org.jboss.test.webservice.jbws309.JBWS309TestCase running under JACC
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3450
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3450
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Security
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> EJBContext.isCallerInRole checks now goes through the JACC layer. (http://jira.jboss.com/jira/browse/JBAS-2661)
> So there may be changes needed in the ejb-jar.xml wrt security role-refs

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:11:44 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Tue, 21 Aug 2007 09:11:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1043) ProcessDefinition
 delete throws
 HibernateException: null index column for collection: org.
 jbpm.graph.def.ProcessDefinition.actions
Message-ID: <1819964.1187701904099.JavaMail.jira@cloud.prod.atl2.jboss.com>

ProcessDefinition delete throws HibernateException: null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 
------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPM-1043
                 URL: http://jira.jboss.com/jira/browse/JBPM-1043
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: Martin Putz
         Assigned To: Tom Baeyens


if the process definition contains a task with notify="yes", eg.

	<task-node name="mail">
		<task name="email info" notify="yes">
			<assignment actor-id="mputz"></assignment>
		</task>
		<transition to="end-state1"></transition>
	</task-node>

the deletion of this process definition results in the stated HibernateException:
null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:16:18 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Tue, 21 Aug 2007 09:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1043) ProcessDefinition
 delete throws
 HibernateException: null index column for collection: org.
 jbpm.graph.def.ProcessDefinition.actions
In-Reply-To: <1819964.1187701904099.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30665904.1187702178458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1043?page=all ]

Martin Putz updated JBPM-1043:
------------------------------

    Attachment: JBPM-1043.patch.txt

attached patch for JpdlXmlReader - the Action object was not set up properly on notify="yes" marked tasks

> ProcessDefinition delete throws HibernateException: null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1043
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1043
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: Martin Putz
>         Assigned To: Tom Baeyens
>         Attachments: JBPM-1043.patch.txt
>
>
> if the process definition contains a task with notify="yes", eg.
> 	<task-node name="mail">
> 		<task name="email info" notify="yes">
> 			<assignment actor-id="mputz"></assignment>
> 		</task>
> 		<transition to="end-state1"></transition>
> 	</task-node>
> the deletion of this process definition results in the stated HibernateException:
> null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:47:32 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:47:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
Message-ID: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add EJB2.x JMX metrics to EJB3
------------------------------

                 Key: EJBTHREE-1033
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC9 - Patch 1
            Reporter: Carlo de Wolf
         Assigned To: William DeCoste
             Fix For: AS 4.2.0 GA


Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount

Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize

MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:47:32 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:47:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4681014.1187704052722.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf updated EJBTHREE-1033:
------------------------------------

    Fix Version/s: EJB 3.0 RC11 - FD
                       (was: AS 4.2.0 GA)
         Assignee: Carlo de Wolf  (was: William DeCoste)

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:49:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14692018.1187704158425.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1033?page=comments#action_12373130 ] 
            
Carlo de Wolf commented on EJBTHREE-1033:
-----------------------------------------

The counterpart of EJBTHREE-825 for trunk

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:56:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15779980.1187704562822.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1033?page=comments#action_12373145 ] 
            
Carlo de Wolf commented on EJBTHREE-1033:
-----------------------------------------

TODO: mdb

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:59:18 2007
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Tue, 21 Aug 2007 09:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1107) Support for
 multiple pattern in accumulate source pattern
Message-ID: <12689020.1187704758710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support for multiple pattern in accumulate source pattern
---------------------------------------------------------

                 Key: JBRULES-1107
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1107
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Juergen none
         Assigned To: Mark Proctor


Accumulate should support more than one pattern as source pattern. e.g.:

Number() from accumulate(
    Cheese(
        price : price,
        type : type
    )
    Person(
        favouriteCheese == type,
        age > 30
    ),
    sum( price )
)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:17:29 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 10:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1057) Create/update
 DTD/schemas for descriptors.
In-Reply-To: <11332006.1158952801489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32556261.1187705849631.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun resolved JBPORTAL-1057.
------------------------------------

    Resolution: Partially Completed

This is done for WSRP and I don't know what the status of the other DTDs is, nor if it's important at this point. Resolving for now, will re-open if there's a strong client need.

> 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 Reference Guide
>    Affects Versions: 2.6.Alpha1
>            Reporter: Chris Laprun
>            Priority: Minor
>             Fix For: 2.4.3 Final
>
>         Attachments: jboss-portlet.dtd, jboss-wsrp.dtd, portlet-instances.dtd, portlet-object.dtd
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:19:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 10:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1141) use binaries
 under jbossas instead of portal while running portal testsuite
In-Reply-To: <16762511.1164666295798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <147849.1187705958233.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun resolved JBPORTAL-1141.
------------------------------------

    Resolution: Won't Fix

It's been determined that the efforts involved to solve this issue are not worth the time: without a profile notion, this would be rather complicated to set up as there are some dependences on thirdparty as well.

> use binaries under jbossas instead of portal while running portal testsuite
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1141
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1141
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>    Affects Versions: 2.4 Final
>            Reporter: Prabhat Jha
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.4.3 Final
>
>
> WSRP tests had failed while testing portal2.4.1.CR1 with jboss4.0.5 because there was a mismatch in webservices binary versions. To remove this conflict, it would be better if portal testsuite could point to jbossas binaries instead of binaries under portal/thirdparty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:21:22 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Tue, 21 Aug 2007 10:21:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <765933.1187706082450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12373162 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

so close this issue and reopen a new one? or discuss this 'recursion' on the dev list.

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:53:29 2007
From: jira-events at lists.jboss.org (Anders Persson (JIRA))
Date: Tue, 21 Aug 2007 10:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-580) Possible to get the
 channel into an incorrect and/or inconsistent state
Message-ID: <13608722.1187708009162.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible to get the channel into an incorrect and/or inconsistent state
-----------------------------------------------------------------------

                 Key: JGRP-580
                 URL: http://jira.jboss.com/jira/browse/JGRP-580
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
         Environment: Windows XP; java 1.5.0_12
            Reporter: Anders Persson
         Assigned To: Bela Ban


The channel is trying to establish a connection. While trying to create the connection there is a Event.EXIT traversed up the stack. This will close the channel and at the same time release connect(). The problem is that when the thread returns to connect() it will continue as if the connect is continuing successfully. This will result in a channel which is set to be connected even though it is actually closed. This will also cause the auto reconnect to fail since the channel considers itself to be connected.

After this long description I think that the following snippet of code will provide a better description.

Today in JChannel the code looks like this:
    public synchronized void connect(String cluster_name) throws ChannelException {
...stuff going on...
            Event connect_event = new Event(Event.CONNECT, cluster_name);
            Object res = downcall(connect_event); // waits forever until
            // connected (or channel is
            // closed)
                if (res != null && res instanceof Exception) { // the JOIN was
                    // rejected by the
                    // coordinator
                    throw new ChannelException("connect() failed", (Throwable) res);
                }

This should be changed to:

            Event connect_event = new Event(Event.CONNECT, cluster_name);
            Object res = downcall(connect_event); // waits forever until
            // connected (or channel is
            // closed)

            /*
             * This is an added section to this method. The if statement will
             * check if the downcall method returned as a result of an
             * Event.EXIT. If so then we should consider this channel to be NOT
             * connected. Otherwise connected will be set to true and any
             * further calls to connect will fail (also auto reconnect will fail
             * for this reason).
             */
            if (!closed) {
                if (res != null && res instanceof Exception) { // the JOIN was
                    // rejected by the
                    // coordinator
                    throw new ChannelException("connect() failed", (Throwable) res);
                }

It obviously has to be verified that the closed flag is set before calling any stop methods on the protocols.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 11:06:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-399) Create retro
 builds for javaee project
Message-ID: <6688898.1187708778359.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create retro builds for javaee project
--------------------------------------

                 Key: JBBUILD-399
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-399
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Create jdk14 retro builds for the javaee subproject of 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 lists.jboss.org  Tue Aug 21 11:08:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-399) Create retro
 builds for javaee project
In-Reply-To: <6688898.1187708778359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20642756.1187708898319.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-399?page=all ]

Paul Gier reassigned JBBUILD-399:
---------------------------------

    Assignee: Paul Gier

> Create retro builds for javaee project
> --------------------------------------
>
>                 Key: JBBUILD-399
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-399
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>
> Create jdk14 retro builds for the javaee subproject of 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 lists.jboss.org  Tue Aug 21 11:34:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-400) Create retro
 builds for AS integration project
Message-ID: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create retro builds for AS integration project
----------------------------------------------

                 Key: JBBUILD-400
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
    Affects Versions: Maven Build - App Server
            Reporter: Paul Gier


Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 11:34:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-400) Create retro
 builds for AS integration project
In-Reply-To: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15774241.1187710458549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-400?page=all ]

Paul Gier reassigned JBBUILD-400:
---------------------------------

    Assignee: Paul Gier

> Create retro builds for AS integration project
> ----------------------------------------------
>
>                 Key: JBBUILD-400
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>    Affects Versions: Maven Build - App Server
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 11:34:19 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Tue, 21 Aug 2007 11:34:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8196133.1187710459100.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=all ]

Manik Surtani updated JBCACHE-1166:
-----------------------------------

    Fix Version/s: 2.1.0.GA

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Tue Aug 21 11:38:18 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Tue, 21 Aug 2007 11:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1165) Endless loop in
 PessimisticLockInterceptor
In-Reply-To: <14669904.1187336057521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10290441.1187710698292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1165?page=all ]

Manik Surtani updated JBCACHE-1165:
-----------------------------------

    Fix Version/s: 1.4.1.SP5

> Endless loop in PessimisticLockInterceptor
> ------------------------------------------
>
>                 Key: JBCACHE-1165
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.SP5
>
>         Attachments: ConcurentPutRemoveTest.java, ConsoleOut.log
>
>
> When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop.
> Main loop looks like:
> 				for (int x = 0; x < 1000; x++) {
> 					tm.begin();
> 					System.out.println("R" + Thread.currentThread().getName());
> 					//inside transaction
> 					cache.remove("/a");
> 					System.out.println("AR" + Thread.currentThread().getName());
> 					tm.commit();
> 					//outside transaction
> 					System.out.println("P" + Thread.currentThread().getName());
> 					cache.put("/a/b/c/d", "text"+x,"b");
> 					System.out.println("AP" + Thread.currentThread().getName());
> 				}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 11:46:32 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 21 Aug 2007 11:46:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-629) Unneccessary
 puts in message store
In-Reply-To: <10858183.1162379381434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10835610.1187711192649.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-629:
--------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: 2.0.0 Beta 1)

> Unneccessary puts in message store
> ----------------------------------
>
>                 Key: JBMESSAGING-629
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-629
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.GA, 1.2.0.Alpha1
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> We are currently executing unnecessary puts into the message store on the primary execution path of message routing.
> When a new message arrives - it is first added to the message store. The message is only ever retrieved from the message store if a reference is loaded from paging and we want to make sure we do not have more than once instance in memory at once.
> The first put is therefore unnecessary and will have some performance implications. Also message store is currently a synchronization bottleneck so this should aid concurrency. Messages should only be added to the message store (if necessary) when they are paged to storage

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 11:46:32 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 21 Aug 2007 11:46:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-629) Unneccessary
 puts in message store
In-Reply-To: <10858183.1162379381434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27791890.1187711192775.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-629.
-------------------------------

    Resolution: Done

> Unneccessary puts in message store
> ----------------------------------
>
>                 Key: JBMESSAGING-629
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-629
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.GA, 1.2.0.Alpha1
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> We are currently executing unnecessary puts into the message store on the primary execution path of message routing.
> When a new message arrives - it is first added to the message store. The message is only ever retrieved from the message store if a reference is loaded from paging and we want to make sure we do not have more than once instance in memory at once.
> The first put is therefore unnecessary and will have some performance implications. Also message store is currently a synchronization bottleneck so this should aid concurrency. Messages should only be added to the message store (if necessary) when they are paged to storage

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:10:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Tue, 21 Aug 2007 13:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1167) Heuristic outcome
 (STATUS_UNKNOWN) of transaction not handled properly
Message-ID: <9760798.1187716218788.JavaMail.jira@cloud.prod.atl2.jboss.com>

Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
----------------------------------------------------------------------

                 Key: JBCACHE-1167
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1167
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.1.SP4, 2.0.0.GA
            Reporter: Galder Zamarreno
         Assigned To: Manik Surtani
             Fix For: 1.4.1.SP5


Where an XA transaction has a heuristic outcome, the status reported to 
the afterCompletion synchronization is STATUS_UNKNOWN (5), since 
JTA does not handle heuristics. In this case, the cache Synchronization 
fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked) 
state even though the XA transaction has been resolved. 

At first glance it looks like the afterCompletion synchronization should treat a 
STATUS_UNKNOWN as a cause for rollback as well as logging the error as 
they currently do. Unfortunately the fix may be more complex than that, since 
the db may have committed rather than rolled back, meaning the cache would 
be out of sync with the db if you rolled it 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 lists.jboss.org  Tue Aug 21 13:10:19 2007
From: jira-events at lists.jboss.org (Elias Ross (JIRA))
Date: Tue, 21 Aug 2007 13:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4618) Thread context
 classloader not set during transaction commit
Message-ID: <26613768.1187716219333.JavaMail.jira@cloud.prod.atl2.jboss.com>

Thread context classloader not set during transaction commit
------------------------------------------------------------

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


I modified a serializable object, part of an EJB3 Entity, during an MDB.onMessage() call. Hibernate attempts to update this serializable object during the transaction commit, but fails because it cannot load the class from the classloader. For example, if one modifies an entity such as:

@Entity
public class Foo {
  Serializable bar;
...
}

in an MDB

public class MDB implements MessageListener {
  @PersistenceContext
  EntityManager em;
  public void onMessage() {
    Foo f = em.load(...);
    f.setBar(new ScopedClass());
  }
}

you get this error.

The thread context classloader is assigned when processing the message. Is it cleared after message processing or after transaction completion? From my limited understanding of the code, it seems like the former. There appears to be an invoker that sets and clears during processing, but the clear apparently happens before transaction commit.

Ordinarily, transaction commit does not require the context classloader of the .ear file, but in this case it 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 lists.jboss.org  Tue Aug 21 13:10:21 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:10:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1639) Let the
 administrator enable or disable a user
In-Reply-To: <17294032.1187352901536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18216425.1187716221925.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Emanuel Muckenhuber resolved JBPORTAL-1639.
-------------------------------------------

    Resolution: Done

the admin can now enable/disable users in the user management

> Let the administrator enable or disable a user 
> -----------------------------------------------
>
>                 Key: JBPORTAL-1639
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1639
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:12:18 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1638) Modify "edit
 profile" to let modification of email and password
In-Reply-To: <8183870.1187352782096.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14962956.1187716338710.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Emanuel Muckenhuber resolved JBPORTAL-1638.
-------------------------------------------

    Resolution: Done

admin can change the email address and reset the password of a user. 

> Modify "edit profile" to let modification of email and password 
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-1638
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1638
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:12:18 2007
From: jira-events at lists.jboss.org (Elias Ross (JIRA))
Date: Tue, 21 Aug 2007 13:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4618) Thread context
 classloader not set during transaction commit
In-Reply-To: <26613768.1187716219333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31728611.1187716338942.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4618?page=comments#action_12373196 ] 
            
Elias Ross commented on JBAS-4618:
----------------------------------

This is with JBoss 4.2.0.

And by "this error", I mean this exception

2007-07-25 11:14:41,313 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.type.SerializationException: could not deserialize
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:214)
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:240)
at org.hibernate.type.SerializableType.fromBytes(SerializableType.java:82)
at org.hibernate.type.SerializableType.deepCopyNotNull(SerializableType.java:74)
at org.hibernate.type.MutableType.deepCopy(MutableType.java:25)
at org.hibernate.type.SerializableToBlobType.deepCopy(SerializableToBlobType.java:102)
at org.hibernate.type.TypeFactory.deepCopy(TypeFactory.java:353)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:114)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:249)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1256)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:494)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:248)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: com.example.msg.ScopedClass
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:514)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:408)
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:574)
at org.hibernate.util.SerializationHelper$CustomObjectInputStream.resolveClass(SerializationHelper.java:268)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538)
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.readObject(ObjectInputStream.java:339)
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:210)
... 28 more	


> Thread context classloader not set during transaction commit
> ------------------------------------------------------------
>
>                 Key: JBAS-4618
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4618
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Elias Ross
>
> I modified a serializable object, part of an EJB3 Entity, during an MDB.onMessage() call. Hibernate attempts to update this serializable object during the transaction commit, but fails because it cannot load the class from the classloader. For example, if one modifies an entity such as:
> @Entity
> public class Foo {
>   Serializable bar;
> ...
> }
> in an MDB
> public class MDB implements MessageListener {
>   @PersistenceContext
>   EntityManager em;
>   public void onMessage() {
>     Foo f = em.load(...);
>     f.setBar(new ScopedClass());
>   }
> }
> you get this error.
> The thread context classloader is assigned when processing the message. Is it cleared after message processing or after transaction completion? From my limited understanding of the code, it seems like the former. There appears to be an invoker that sets and clears during processing, but the clear apparently happens before transaction commit.
> Ordinarily, transaction commit does not require the context classloader of the .ear file, but in this case it 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 lists.jboss.org  Tue Aug 21 13:12:19 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:12:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1636) Captcha support
 (with jcpatcha probably)
In-Reply-To: <32032096.1187352781527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11808504.1187716339100.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Emanuel Muckenhuber resolved JBPORTAL-1636.
-------------------------------------------

    Resolution: Done

added captcha (jcaptcha) for registering and for requesting a new password

> Captcha support (with jcpatcha probably) 
> -----------------------------------------
>
>                 Key: JBPORTAL-1636
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1636
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:14:18 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1635) Lost password
 feature, attribute a random password and send it by email
In-Reply-To: <26661164.1187352668657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5035347.1187716458642.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Emanuel Muckenhuber resolved JBPORTAL-1635.
-------------------------------------------

    Resolution: Done

The user can now request a new password by using his username.

> Lost password feature, attribute a random password and send it by email 
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1635
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1635
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:14:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1641) Portal link (top
 right of page) in admin results in 403 error
Message-ID: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portal link (top right of page) in admin results in 403 error
-------------------------------------------------------------

                 Key: JBPORTAL-1641
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.8 Final
            Reporter: Chris Laprun
             Fix For: 2.8 Final


Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:18:19 2007
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Tue, 21 Aug 2007 13:18:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1051) Failure of
 one JMS Server may cause VIEW to not propogate in JBM cluster
Message-ID: <4493142.1187716699014.JavaMail.jira@cloud.prod.atl2.jboss.com>

Failure of one JMS Server may cause VIEW to not propogate in JBM cluster
------------------------------------------------------------------------

                 Key: JBMESSAGING-1051
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1051
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.0.CR1
         Environment:  JBoss 4.2.1 EAP with JBM 1.4 HEAD running on two CentOS5  servers with a shared MySQL 5.x db.
            Reporter: Ray Ploski
         Assigned To: Tim Fox


In a two-node JBM cluster, after one of the nodes is hard-killed (kill -9), the server cannot be restarted.  

An "IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id ([MY_SERVER_NODE]). Are you sure you have given each node a unique node id during installation?" occurs semi-frequently in a two-node JBM cluster.  

While looking at the surviving node, you can see all members of the view (both the dead and alive) in the PostOffice.NodeIDView.


A restart of all members of the cluster is required to resolve the issue.  

 ERROR [org.jboss.messaging.util.ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService at 456a5c7c startService
java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (172). Are you sure you have given each node a unique node id during installation?
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:335)
        at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:413)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
        at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
        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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:417)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        ..


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:26:18 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Tue, 21 Aug 2007 13:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1167) Heuristic outcome
 (STATUS_UNKNOWN) of transaction not handled properly
In-Reply-To: <9760798.1187716218788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8588727.1187717178646.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1167?page=all ]

Manik Surtani updated JBCACHE-1167:
-----------------------------------

    JBoss Forum Reference: http://lists.jboss.org/pipermail/jbosscache-dev/2007-August/001968.html

> Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-1167
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1167
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.4.1.SP4
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.SP5
>
>
> Where an XA transaction has a heuristic outcome, the status reported to 
> the afterCompletion synchronization is STATUS_UNKNOWN (5), since 
> JTA does not handle heuristics. In this case, the cache Synchronization 
> fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked) 
> state even though the XA transaction has been resolved. 
> At first glance it looks like the afterCompletion synchronization should treat a 
> STATUS_UNKNOWN as a cause for rollback as well as logging the error as 
> they currently do. Unfortunately the fix may be more complex than that, since 
> the db may have committed rather than rolled back, meaning the cache would 
> be out of sync with the db if you rolled it 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 lists.jboss.org  Tue Aug 21 13:35:18 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 21 Aug 2007 13:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
Message-ID: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add parseRoleNameFromDN option to LdapExtLoginModule
----------------------------------------------------

                 Key: JBAS-4619
                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Mike Millson
         Assigned To: Scott M Stark


Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 

The option would look something like:

<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleNameAttributeID">myprofile</module-option>
<module-option name="parseRoleNameFromDN">true</module-option>

Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:41:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 21 Aug 2007 13:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-795) Allow bisocket
 server to run behind a NAT router
Message-ID: <767687.1187718078471.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow bisocket server to run behind a NAT router
------------------------------------------------

                 Key: JBREM-795
                 URL: http://jira.jboss.com/jira/browse/JBREM-795
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.2.0.SP4_CP02
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.2.GA, 2.2.0.SP4_CP02


When org.jboss.remoting.transport.bisocket.BisocketServerInvoker received a request to return the address of the secondary ServerSocket, it returns ServerSocket.getInetAddress().getHostAddress(), which may not be accessible to the outside world.  

The secondary ServerSocket should be configurable just like the primary ServerSocket, which has parameters "serverBindAddress", "serverBindPort", "clientConnectAddress", and "clientConnectPort".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:43:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 21 Aug 2007 13:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBREM-795) Allow bisocket
 server to run behind a NAT router
Message-ID: <30339254.1187718198377.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal deleted JBREM-795:
----------------------------


> Allow bisocket server to run behind a NAT router
> ------------------------------------------------
>
>                 Key: JBREM-795
>                 URL: http://jira.jboss.com/jira/browse/JBREM-795
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>
> When org.jboss.remoting.transport.bisocket.BisocketServerInvoker received a request to return the address of the secondary ServerSocket, it returns ServerSocket.getInetAddress().getHostAddress(), which may not be accessible to the outside world.  
> The secondary ServerSocket should be configurable just like the primary ServerSocket, which has parameters "serverBindAddress", "serverBindPort", "clientConnectAddress", and "clientConnectPort".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 14:16:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1642) Usability
	improvements
Message-ID: <14088977.1187720178310.JavaMail.jira@cloud.prod.atl2.jboss.com>

Usability improvements
----------------------

                 Key: JBPORTAL-1642
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1642
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core, Portal Core Admin, Portal WSRP
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.2 Final


Umbrella task for work on usability.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 14:18:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1643) Replace
 "Destroy" by "Delete" where applicable
Message-ID: <14683022.1187720298181.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace "Destroy" by "Delete" where applicable
----------------------------------------------

                 Key: JBPORTAL-1643
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1643
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
            Priority: Minor
             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 21 14:55:30 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:55:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1644) Add Default
 status / Make Default action to object (e.g. portal, page) tables
Message-ID: <4492260.1187722530673.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add Default status / Make Default action to object (e.g. portal, page) tables
-----------------------------------------------------------------------------

                 Key: JBPORTAL-1644
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1644
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 21 14:57:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1642) Usability
	improvements
In-Reply-To: <14088977.1187720178310.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6730692.1187722638217.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun updated JBPORTAL-1642:
-----------------------------------

    Fix Version/s: 2.8 Final

> Usability improvements
> ----------------------
>
>                 Key: JBPORTAL-1642
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1642
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal WSRP, Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Umbrella task for work on usability.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 15:12:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 15:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1643) Replace
 "Destroy" by "Delete" where applicable
In-Reply-To: <14683022.1187720298181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9124972.1187723538210.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun updated JBPORTAL-1643:
-----------------------------------

    Fix Version/s: 2.8 Final

> Replace "Destroy" by "Delete" where applicable
> ----------------------------------------------
>
>                 Key: JBPORTAL-1643
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1643
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 21 15:12:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 15:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1643) Replace
 "Destroy" by "Delete" where applicable
In-Reply-To: <14683022.1187720298181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30435674.1187723538306.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun resolved JBPORTAL-1643.
------------------------------------

    Resolution: Done

> Replace "Destroy" by "Delete" where applicable
> ----------------------------------------------
>
>                 Key: JBPORTAL-1643
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1643
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 21 16:20:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-401) Add support for
 retro-translating javax.xml.namespace.QName
Message-ID: <20808895.1187727618234.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for retro-translating javax.xml.namespace.QName
-----------------------------------------------------------

                 Key: JBBUILD-401
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-401
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


The microcontainer kernel module uses javax.xml.namespace.QName which is a jdk1.5 class.  Support should be added to jboss-retro to retro weave 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 lists.jboss.org  Tue Aug 21 16:26:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 16:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1645) Don't show
 properties table if there are no properties
Message-ID: <9644068.1187727978328.JavaMail.jira@cloud.prod.atl2.jboss.com>

Don't show properties table if there are no properties
------------------------------------------------------

                 Key: JBPORTAL-1645
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1645
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 21 16:30:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-402) Add support for
 jdk1.5 Big Decimal methods
Message-ID: <6024074.1187728218240.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for jdk1.5 Big Decimal methods
------------------------------------------

                 Key: JBBUILD-402
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-402
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
    Affects Versions: JBossRetro-1.1.2.GA
            Reporter: Paul Gier


The class java.math.BigDecimal added several new methods in jdk1.5.  Support for these should be added to the retro weaving.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:30:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-402) Add support for
 jdk1.5 Big Decimal methods
In-Reply-To: <6024074.1187728218240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4373611.1187728218362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-402?page=all ]

Paul Gier updated JBBUILD-402:
------------------------------

    Fix Version/s: JBossRetro-1.1.3.GA

> Add support for jdk1.5 Big Decimal methods
> ------------------------------------------
>
>                 Key: JBBUILD-402
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-402
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>    Affects Versions: JBossRetro-1.1.2.GA
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.1.3.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> The class java.math.BigDecimal added several new methods in jdk1.5.  Support for these should be added to the retro weaving.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:33:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
Message-ID: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add config parameter to specify groupId in jboss deploy plugin
--------------------------------------------------------------

                 Key: JBBUILD-403
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: maven-jboss-deploy-plugin
    Affects Versions: maven-jboss-deploy-plugin-1.3
            Reporter: Paul Gier


Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:37:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
In-Reply-To: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5629046.1187728638456.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-403?page=all ]

Paul Gier updated JBBUILD-403:
------------------------------

    Fix Version/s: maven-jboss-deploy-plugin-1.4

> Add config parameter to specify groupId in jboss deploy plugin
> --------------------------------------------------------------
>
>                 Key: JBBUILD-403
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-deploy-plugin
>    Affects Versions: maven-jboss-deploy-plugin-1.3
>            Reporter: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:37:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-404) Create project
 site for jboss-deploy plugin.
Message-ID: <27716106.1187728638760.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create project site for jboss-deploy plugin.
--------------------------------------------

                 Key: JBBUILD-404
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-404
             Project: JBoss Build System
          Issue Type: Task
          Components: maven-jboss-deploy-plugin
            Reporter: Paul Gier
             Fix For: maven-jboss-deploy-plugin-1.4


There should be a project site that contains documentation for the plugin on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:43:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 16:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1645) Don't show
 properties table if there are no properties
In-Reply-To: <9644068.1187727978328.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <79384.1187728998852.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun resolved JBPORTAL-1645.
------------------------------------

       Resolution: Done
    Fix Version/s: 2.8 Final
                   2.6.2 Final

> Don't show properties table if there are no properties
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1645
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1645
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 21 16:45:48 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 16:45:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1645) Don't show
 properties table if there are no properties
In-Reply-To: <9644068.1187727978328.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32983307.1187729148787.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun updated JBPORTAL-1645:
-----------------------------------

    Affects Version/s: 2.6.1 Final
          Component/s: Portal Core Admin

> Don't show properties table if there are no properties
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1645
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1645
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Tue Aug 21 16:49:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-405) Research issue with
 microcontainer kernel retro builds
Message-ID: <13171755.1187729358453.JavaMail.jira@cloud.prod.atl2.jboss.com>

Research issue with microcontainer kernel retro builds
------------------------------------------------------

                 Key: JBBUILD-405
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-405
             Project: JBoss Build System
          Issue Type: Task
          Components: JBossRetro, Maven
            Reporter: Paul Gier
             Fix For: Maven Build - Maint 2007


The microcontainer kernel is not able to compile with dependency on retroed version of jboss-container.  It compiles ok depending on the regular container, but with the retro container, there is a problem with the annotations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:55:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:55:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-406) Create retro build
	for aop
Message-ID: <1127269.1187729719337.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create retro build for aop
--------------------------

                 Key: JBBUILD-406
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-406
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


AOP needs a retro 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 lists.jboss.org  Tue Aug 21 16:57:29 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-399) Create retro builds
 for javaee project
In-Reply-To: <6688898.1187708778359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17090031.1187729849179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-399?page=all ]

Paul Gier closed JBBUILD-399.
-----------------------------

    Resolution: Done

Poms for retro build have been added.

> Create retro builds for javaee project
> --------------------------------------
>
>                 Key: JBBUILD-399
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-399
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>
> Create jdk14 retro builds for the javaee subproject of 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 lists.jboss.org  Tue Aug 21 16:59:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-400) Create retro
 builds for AS integration project
In-Reply-To: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32532554.1187729958438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-400?page=all ]

Paul Gier updated JBBUILD-400:
------------------------------

    Affects Version/s:     (was: Maven Build - App Server)
        Fix Version/s: Maven Build - App Server

> Create retro builds for AS integration project
> ----------------------------------------------
>
>                 Key: JBBUILD-400
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 16:59:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-400) Create retro builds
 for AS integration project
In-Reply-To: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29788361.1187729958662.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-400?page=all ]

Paul Gier closed JBBUILD-400.
-----------------------------

    Resolution: Done

Poms for a retro build of the integration project have been added.

> Create retro builds for AS integration project
> ----------------------------------------------
>
>                 Key: JBBUILD-400
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 17:07:32 2007
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 21 Aug 2007 17:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1034) Port
 ejb3/src/main/org/jboss/ejb3/enc/DeploymentPersistenceUnitResolver.java to
 Branch_4_2
Message-ID: <22376933.1187730452121.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port ejb3/src/main/org/jboss/ejb3/enc/DeploymentPersistenceUnitResolver.java to Branch_4_2
------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1034
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1034
             Project: EJB 3.0
          Issue Type: Patch
    Affects Versions: AS 4.2.2.GA
            Reporter: Frank Langelage
             Fix For: AS 4.2.2.GA


Port the changes made on ejb3/src/main/org/jboss/ejb3/enc/DeploymentPersistenceUnitResolver.java in Head to Branch 4.2.
Using an ear with seperated session and entity beans (different ejb-modules) I got the exception "There is no default persistence nit in this deployment." when using "@PersistenceContext private EntityManager entityManager;" in my Session Bean.
Using the head version of the source file within my 4.2.2.GA cvs checkout the problem went away.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 17:07:32 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 17:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1644) Add Default
 status / Make Default action to object (e.g. portal, page) tables
In-Reply-To: <4492260.1187722530673.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1130647.1187730452212.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun updated JBPORTAL-1644:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final

> Add Default status / Make Default action to object (e.g. portal, page) tables
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1644
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1644
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Tue Aug 21 17:29:53 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 17:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-93) Add
 JBossRetro builds for Microcontainer projects
Message-ID: <7690033.1187731793352.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=comments#action_12373237 ] 
            
Paul Gier commented on JBMICROCONT-93:
--------------------------------------

As I'm creating and testing the retro poms, I've found several missing features in JBoss retro that will need to be implemented to get all the tests working.  I've created jira issues under the jboss retro project for the missing features.

> Add JBossRetro builds for Microcontainer projects
> -------------------------------------------------
>
>                 Key: JBMICROCONT-93
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93
>             Project: JBoss MicroContainer
>          Issue Type: Sub-task
>          Components: General
>            Reporter: Adrian Brock
>         Assigned To: Paul Gier
>             Fix For: JBossMC-2.0.0.CR1
>
>
> Make JBossRetro builds for the microcontainer projects
> such that they can use JDK5 features.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 18:54:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 18:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-580) Possible to get the
 channel into an incorrect and/or inconsistent state
In-Reply-To: <13608722.1187708009162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19557420.1187736858887.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-580:
--------------------------

    Fix Version/s: 2.6

> Possible to get the channel into an incorrect and/or inconsistent state
> -----------------------------------------------------------------------
>
>                 Key: JGRP-580
>                 URL: http://jira.jboss.com/jira/browse/JGRP-580
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1.5.0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The channel is trying to establish a connection. While trying to create the connection there is a Event.EXIT traversed up the stack. This will close the channel and at the same time release connect(). The problem is that when the thread returns to connect() it will continue as if the connect is continuing successfully. This will result in a channel which is set to be connected even though it is actually closed. This will also cause the auto reconnect to fail since the channel considers itself to be connected.
> After this long description I think that the following snippet of code will provide a better description.
> Today in JChannel the code looks like this:
>     public synchronized void connect(String cluster_name) throws ChannelException {
> ...stuff going on...
>             Event connect_event = new Event(Event.CONNECT, cluster_name);
>             Object res = downcall(connect_event); // waits forever until
>             // connected (or channel is
>             // closed)
>                 if (res != null && res instanceof Exception) { // the JOIN was
>                     // rejected by the
>                     // coordinator
>                     throw new ChannelException("connect() failed", (Throwable) res);
>                 }
> This should be changed to:
>             Event connect_event = new Event(Event.CONNECT, cluster_name);
>             Object res = downcall(connect_event); // waits forever until
>             // connected (or channel is
>             // closed)
>             /*
>              * This is an added section to this method. The if statement will
>              * check if the downcall method returned as a result of an
>              * Event.EXIT. If so then we should consider this channel to be NOT
>              * connected. Otherwise connected will be set to true and any
>              * further calls to connect will fail (also auto reconnect will fail
>              * for this reason).
>              */
>             if (!closed) {
>                 if (res != null && res instanceof Exception) { // the JOIN was
>                     // rejected by the
>                     // coordinator
>                     throw new ChannelException("connect() failed", (Throwable) res);
>                 }
> It obviously has to be verified that the closed flag is set before calling any stop methods on the protocols.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 21:11:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 21:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33482974.1187745078337.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1086:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 21:53:34 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 21:53:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1028) importing
 .brxml into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31984118.1187747614475.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=comments#action_12373246 ] 
            
Michael Neale commented on JBRULES-1028:
----------------------------------------

For some more details on how to do this: 

BRXMLPersistence.getInstance().unmarshal -- this gives a RuleModel from the XML
BRDRLPersistence.getinstance.marshal - this takes the RuleModel and dumps out the DRL
The name in the RuleModel SHOULD be the same as the file that it came from. If its not, it would be best to set it to the same as the file (minus the extension).

The DRL can then be added to the PackageBuilder - of course this will also need the imports added beforehand etc (and the package name). 

In the BRMS this is all done with ContentpackageAssembler. In the IDE, the Guided editor will create some .package file that contains the imports etc... thats how the editor knows what to work with. 

This code will need to cater for that. So we can either make people use package builder plus the above, OR we can enhance package builder, OR we create an ant task to automate it all.

If we have an ant task, it needs to cater for ALL asset types (like the BRMS does) - that includes decision tables, .dslr rules (loading up the dsl files) and ruleflows, adding it all to a package. Thus the ant task can be pointed at a folder and it will do the rest (of course it needs a classpath).



> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Tue Aug 21 21:55:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 21:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23129056.1187747718340.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale reassigned JBRULES-1083:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 22:00:18 2007
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Tue, 21 Aug 2007 22:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1051) Failure of
 one JMS Server may cause VIEW to not propogate in JBM cluster
In-Reply-To: <4493142.1187716699014.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31842317.1187748018409.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1051?page=comments#action_12373247 ] 
            
Ray Ploski commented on JBMESSAGING-1051:
-----------------------------------------

Found that this issue is related to using an unsupported MySQL engine - the clustering ndb engine.  This is related to mysql bug: http://bugs.mysql.com/bug.php?id=9144. Catching the exception and re-invoking the executeQuery is enough to make this work.

The error listed below comes from the surviving node of the cluster:

2007-08-21 11:43:01,779 2097431 ERROR [org.jgroups.protocols.UDP] @IncomingPacketHandler (channel=MessagingPostOffice) failed unmarshalling message
java.lang.IllegalStateException: General error message from server: "Got error 241 'Invalid schema object version' from ndbcluster"
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2001)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1168)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1279)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:2281)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1634)
        at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:236)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.mergeAndLoad(JDBCPersistenceManager.java:933)
        at org.jboss.messaging.core.impl.MessagingQueue.mergeIn(MessagingQueue.java:217)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.performFailover(MessagingPostOffice.java:2924)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:901)
        at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:469)
        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:735)
        at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
        at org.jgroups.JChannel.up(JChannel.java:1091)
        at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
        at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:487)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
        at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:568)
        at org.jgroups.protocols.pbcast.GMS.up(GMS.java:707)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)

> Failure of one JMS Server may cause VIEW to not propogate in JBM cluster
> ------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1051
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1051
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.CR1
>         Environment:  JBoss 4.2.1 EAP with JBM 1.4 HEAD running on two CentOS5  servers with a shared MySQL 5.x db.
>            Reporter: Ray Ploski
>         Assigned To: Tim Fox
>
> In a two-node JBM cluster, after one of the nodes is hard-killed (kill -9), the server cannot be restarted.  
> An "IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id ([MY_SERVER_NODE]). Are you sure you have given each node a unique node id during installation?" occurs semi-frequently in a two-node JBM cluster.  
> While looking at the surviving node, you can see all members of the view (both the dead and alive) in the PostOffice.NodeIDView.
> A restart of all members of the cluster is required to resolve the issue.  
>  ERROR [org.jboss.messaging.util.ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService at 456a5c7c startService
> java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (172). Are you sure you have given each node a unique node id during installation?
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:335)
>         at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:413)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
>         at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
>         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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:417)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         ..

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 22:10:18 2007
From: jira-events at lists.jboss.org (Luke Maurer (JIRA))
Date: Tue, 21 Aug 2007 22:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1108) Eclipse DRL
 editor unusable on dark background
Message-ID: <28516158.1187748618463.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eclipse DRL editor unusable on dark background
----------------------------------------------

                 Key: JBRULES-1108
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1108
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
         Environment: Eclipse 3.3.0
            Reporter: Luke Maurer
         Assigned To: Mark Proctor


Having a dark background color for editors in Eclipse makes the default DRL syntax highlighting unusable (as is the case with most Eclipse editors). Unfortunately, the editor's syntax highlighting can be neither changed nor disabled, so the DRL editor is completely unusable for me. While fully customizable syntax highlighting would be the best, simply being able to disable it entirely (and use Eclipse's default text color, which I of course have set to white) would be a perfectly good workaround.

I set the background color to black in Preferences -> General -> Editors -> Text Editors -> Background color, and the foreground color to white on the same page.

(Of course, this is really Eclipse's fault for forcing every single editor to have its very own ad-hoc syntax highlighting configuration system ... but I'd better not get started :-) )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 22:45:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 22:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1086) InitialFact should
 not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9879638.1187750718294.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-1086.
----------------------------------

    Resolution: Done

> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 23:51:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 23:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8547307.1187754678298.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-1083.
----------------------------------

    Resolution: Done

Documentation updated (including railroad) to reflect this. The brackets can only ever be optional for a single pattern.

> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 00:19:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 00:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27333004.1187756358292.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373252 ] 
            
Michael Neale commented on JBRULES-1065:
----------------------------------------

This isn't a bug per se - this was not implemented this way.

You can do:

$record : Record( abc == $record.xyz )

I can't see how abc = xyz would work - it would be very very ambiguous for non trivial usage. We could do a:

this.xyz - how does that sound? 

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 02:13:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 02:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18552399.1187763198294.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373258 ] 
            
Michael Neale commented on JBRULES-1065:
----------------------------------------

ok there are 2 ways (this isn't a bug technically): 

You can do $record : Record( abc == $record.xyz)

is that close enough? 

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 04:14:18 2007
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 22 Aug 2007 04:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBADMCON-151) The web-console
 tree does not
 appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so
 plugin
Message-ID: <31546280.1187770458348.JavaMail.jira@cloud.prod.atl2.jboss.com>

The web-console tree does not appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so plugin
----------------------------------------------------------------------------------------------------------------

                 Key: JBADMCON-151
                 URL: http://jira.jboss.com/jira/browse/JBADMCON-151
             Project: JBoss Admin Console
          Issue Type: Bug
         Environment: Server Side
Version
Version: 4.0.5GA(build: CVSTag=Branch_4_0 date=200610162340)
Version Name: Zion
Built on: October 16 2006 

Environment
Start date: Wed Aug 22 09:13:47 CEST 2007
Host: Oops
Base Location: file:/jboss/jboss-portal-2.6/server/
Base Location (local): /jboss/jboss-portal-2.6/server
Running config: 'default

Hardware
#CPU: 1
OS: Linux 2.6.20-2925.9.fc7xen (i386)

JVM Environment
Free Memory: 49 MB
Max Memory: 506 MB
Total Memory: 126 MB
#Threads: 42
JVM Version: 1.6.0-b105 (Sun Microsystems Inc.)
JVM Name: Java HotSpot(TM) Server VM

Client Side
Hardware
#CPU: 1
OS: Linux 2.6.20-2925.9.fc7xen (i386)
Software
firefox 2.0.0.5

JVM Env
Sun JRE jre1.6.0_02

            Reporter: Frederic Hornain
            Priority: Minor


Hi,

Well, I have set the Java plugin on firefox as described below but I did not managed to see the web-console applets.
it is always a blank page on the left frame and the JBoss? Application Server information on the right frame.

ln -s  /usr/java/latest/plugin/i386/ns7/libjavaplugin_oji.so /home/user/.mozilla/plugins/libjavaplugin_oji.so 

Thanks in advance for your help.

BR
Fred

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Aug 22 04:20:18 2007
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 22 Aug 2007 04:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBADMCON-151) The web-console
 tree does not
 appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so
 plugin
In-Reply-To: <31546280.1187770458348.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32745621.1187770818231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-151?page=all ]

Frederic Hornain updated JBADMCON-151:
--------------------------------------


Hi,

it is me again.
Well, I do not think this problem is linked to Jboss cause I had the same issue with the applets demo from sun - http://java.sun.com/applets/jdk/1.4/index.html -.

Nothing happens.

Keep you in touch if I found how to fix this issue.

BR 
Fred


> The web-console tree does not appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so plugin
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBADMCON-151
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-151
>             Project: JBoss Admin Console
>          Issue Type: Bug
>         Environment: Server Side
> Version
> Version: 4.0.5GA(build: CVSTag=Branch_4_0 date=200610162340)
> Version Name: Zion
> Built on: October 16 2006 
> Environment
> Start date: Wed Aug 22 09:13:47 CEST 2007
> Host: Oops
> Base Location: file:/jboss/jboss-portal-2.6/server/
> Base Location (local): /jboss/jboss-portal-2.6/server
> Running config: 'default
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> JVM Environment
> Free Memory: 49 MB
> Max Memory: 506 MB
> Total Memory: 126 MB
> #Threads: 42
> JVM Version: 1.6.0-b105 (Sun Microsystems Inc.)
> JVM Name: Java HotSpot(TM) Server VM
> Client Side
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> Software
> firefox 2.0.0.5
> JVM Env
> Sun JRE jre1.6.0_02
>            Reporter: Frederic Hornain
>            Priority: Minor
>
> Hi,
> Well, I have set the Java plugin on firefox as described below but I did not managed to see the web-console applets.
> it is always a blank page on the left frame and the JBoss? Application Server information on the right frame.
> ln -s  /usr/java/latest/plugin/i386/ns7/libjavaplugin_oji.so /home/user/.mozilla/plugins/libjavaplugin_oji.so 
> Thanks in advance for your help.
> BR
> Fred

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:38:20 2007
From: jira-events at lists.jboss.org (Wolfgang Hollweck (JIRA))
Date: Wed, 22 Aug 2007 04:38:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1044)
 TaskMgmtInstance.removeSignalling(Token token) - Remove signalling
 capabilities from all task instances related to the given token
Message-ID: <11857253.1187771900133.JavaMail.jira@cloud.prod.atl2.jboss.com>

TaskMgmtInstance.removeSignalling(Token token) - Remove signalling capabilities from all task instances related to the given token
----------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPM-1044
                 URL: http://jira.jboss.com/jira/browse/JBPM-1044
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions: jBPM jPDL 3.2, jBPM 3.1.4
            Reporter: Wolfgang Hollweck
         Assigned To: Tom Baeyens


There is a bug in TaskMgmtinstance.removeSignalling(Token token) of jBPM versions 3.1.4 and 3.2:

Signalling is set to false for all TaskInstances that are in the current TaskMgmtInstance.
It has to be checked, that signalling is removed only from TaskInstances belonging to the given Token.
(see forum)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:40:31 2007
From: jira-events at lists.jboss.org (Wolfgang Hollweck (JIRA))
Date: Wed, 22 Aug 2007 04:40:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1044)
 TaskMgmtInstance.removeSignalling(Token token) - Remove signalling
 capabilities from all task instances related to the given token
In-Reply-To: <11857253.1187771900133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21528751.1187772031853.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1044?page=all ]

Wolfgang Hollweck updated JBPM-1044:
------------------------------------

    Fix Version/s: jBPM jPDL 3.2.2
                   jBPM 4.0
                   jBPM jPDL 3.2 beta 2
                   jBPM 3.1.4

> TaskMgmtInstance.removeSignalling(Token token) - Remove signalling capabilities from all task instances related to the given token
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1044
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1044
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2, jBPM 3.1.4
>            Reporter: Wolfgang Hollweck
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 4.0, jBPM 3.1.4, jBPM jPDL 3.2 beta 2, jBPM jPDL 3.2.2
>
>
> There is a bug in TaskMgmtinstance.removeSignalling(Token token) of jBPM versions 3.1.4 and 3.2:
> Signalling is set to false for all TaskInstances that are in the current TaskMgmtInstance.
> It has to be checked, that signalling is removed only from TaskInstances belonging to the given Token.
> (see forum)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:43:19 2007
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Wed, 22 Aug 2007 04:43:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30325493.1187772199049.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-89?page=all ]

Jean-Frederic Clere reassigned JBWEB-89:
----------------------------------------

    Assignee: Jean-Frederic Clere  (was: Mladen Turk)

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Jean-Frederic Clere
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:47:18 2007
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 22 Aug 2007 04:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBADMCON-151) The web-console
 tree does not
 appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so
 plugin
In-Reply-To: <31546280.1187770458348.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5944976.1187772438418.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-151?page=all ]

Frederic Hornain resolved JBADMCON-151.
---------------------------------------

    Resolution: Done

Hi again,

Finally I found why how to fix it;
Sorry to have disturbing you.

So this is the solution :

1 Open a terminal .

2 Login as root by entering the following.
su - 

3 At the password prompt enter the password for root. 
Install the compatiablility libraries by performing the following:
yum -y install compat-libstdc++-33 compat-libstdc++-296

or search these files on the Fedora Extra repository on the web, download them and install them with the rpm command:
rpm -ivh  install compat-libstdc++-33.rpm compat-libstdc++-296.rpm

4 After the libraries are installed perform the following:
/sbin/ldconfig

Ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib). The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their linksupdated.

Oh yes do not forget to create the symbolic link described above in the problem describtion.

Finally do not forget as well to export the JAVA_HOME and the new PATH environment which could be usefull if you would like to develop in java in your terminal. But i am pretty sure you already know that.

Have fun  with JBOSS
And feel free to contact me if you need more details about this problem.

BR
Fred


> The web-console tree does not appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so plugin
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBADMCON-151
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-151
>             Project: JBoss Admin Console
>          Issue Type: Bug
>         Environment: Server Side
> Version
> Version: 4.0.5GA(build: CVSTag=Branch_4_0 date=200610162340)
> Version Name: Zion
> Built on: October 16 2006 
> Environment
> Start date: Wed Aug 22 09:13:47 CEST 2007
> Host: Oops
> Base Location: file:/jboss/jboss-portal-2.6/server/
> Base Location (local): /jboss/jboss-portal-2.6/server
> Running config: 'default
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> JVM Environment
> Free Memory: 49 MB
> Max Memory: 506 MB
> Total Memory: 126 MB
> #Threads: 42
> JVM Version: 1.6.0-b105 (Sun Microsystems Inc.)
> JVM Name: Java HotSpot(TM) Server VM
> Client Side
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> Software
> firefox 2.0.0.5
> JVM Env
> Sun JRE jre1.6.0_02
>            Reporter: Frederic Hornain
>            Priority: Minor
>
> Hi,
> Well, I have set the Java plugin on firefox as described below but I did not managed to see the web-console applets.
> it is always a blank page on the left frame and the JBoss? Application Server information on the right frame.
> ln -s  /usr/java/latest/plugin/i386/ns7/libjavaplugin_oji.so /home/user/.mozilla/plugins/libjavaplugin_oji.so 
> Thanks in advance for your help.
> BR
> Fred

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 06:07:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Aug 2007 06:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-581) Convert ReplicatedMap
 to ConcurrentHashMap from HashMap
Message-ID: <10186974.1187777238359.JavaMail.jira@cloud.prod.atl2.jboss.com>

Convert ReplicatedMap to ConcurrentHashMap from HashMap
-------------------------------------------------------

                 Key: JGRP-581
                 URL: http://jira.jboss.com/jira/browse/JGRP-581
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix 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 lists.jboss.org  Wed Aug 22 07:00:18 2007
From: jira-events at lists.jboss.org (Shahad Ahmed (JIRA))
Date: Wed, 22 Aug 2007 07:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1109) Exported BRMS
 repositories lose version history
Message-ID: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exported BRMS repositories lose version history
-----------------------------------------------

                 Key: JBRULES-1109
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Windows XP SP2, SUN JRE 1.5_09
            Reporter: Shahad Ahmed
         Assigned To: Mark Proctor


I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.

If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?

Here's how to replicate the problem for a clean BRMS install:

1. Create a new category called test.

2. In the defaultPackage create a new technical rule called test as shown below:

when
    eval(true)
then
    System.out.println("Hello");

3. Save the test rule

4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.

5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.

6. From Admin/Manage Backups save the repository.

7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).

8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 07:24:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Aug 2007 07:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-581) Convert
 ReplicatedMap to ConcurrentHashMap from HashMap
In-Reply-To: <10186974.1187777238359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24350364.1187781858195.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-581.
---------------------------

    Resolution: Done

> Convert ReplicatedMap to ConcurrentHashMap from HashMap
> -------------------------------------------------------
>
>                 Key: JGRP-581
>                 URL: http://jira.jboss.com/jira/browse/JGRP-581
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix 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 lists.jboss.org  Wed Aug 22 07:34:19 2007
From: jira-events at lists.jboss.org (Anders Persson (JIRA))
Date: Wed, 22 Aug 2007 07:34:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
In-Reply-To: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25894897.1187782459496.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anders Persson reopened JGRP-578:
---------------------------------

             
Well, I would definitely not make JChannel depend on the leaving flag in GMS. In my view JChannel should be kept complety protocol neutral.

The solution I see is to introduce an abort method in Protocol. Calling this method would have the effect that the protocol (subclass to Protocol) ceases its current blocking activites, much like you have an "abort flag" that you every now and then check when you are running a thread. The contract would then be that a protocol is obliged to implement abort in case it has any blocking activities. In the case of GMS it would mean that abort() would do the same as stop(), that is, set the leaving flag to true.

The pseudo code in JChannel would be something like

public close()
protocolStack.abort()
synchronized(this)

In other words the synchronized block is only started once the abort has been called. You would keep the synchronized statement on the connect method as is. The synchronization ensures that connect() will finish its business before close() proceeds. I see this as a simple and clean approach to solve this issue. It is a generic way to implement the workaround already described.

> It is possible to create a deadlock when trying to close a channel which is not yet connected
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-578
>                 URL: http://jira.jboss.com/jira/browse/JGRP-578
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1_5_0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.
> Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Wed Aug 22 07:42:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 22 Aug 2007 07:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4620) NPE in EJB3
 Authentication Interceptor
Message-ID: <12500267.1187782938496.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE in EJB3 Authentication Interceptor
--------------------------------------

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


Most EJB3 web service tests fail because of 

java.lang.NullPointerException
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:141)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
        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.wsf.container.jboss50.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:104)
        at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:220)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 07:44:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 22 Aug 2007 07:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4620) NPE in EJB3
 Authentication Interceptor
In-Reply-To: <12500267.1187782938496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6267908.1187783058505.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4620?page=comments#action_12373288 ] 
            
Thomas Diesler commented on JBAS-4620:
--------------------------------------

I already made  the jbossws container integration an integral part of the AS code base 

The issue is probably caused by invalid security code in org.jboss.wsf.container.jboss50.InvocationHandlerEJB3 which you will find in the newly created webservices module

To easily reproduce the issue, please follow 
http://jbws.dyndns.org/mediawiki/index.php?title=Building_From_Source#Checkout_and_build_JBossWS-Native

Hudson shows this regression here
http://jbws.dyndns.org:8280/hudson/job/Integration-Native-AS-5.0/

> NPE in EJB3 Authentication Interceptor
> --------------------------------------
>
>                 Key: JBAS-4620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Anil Saldhana
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Most EJB3 web service tests fail because of 
> java.lang.NullPointerException
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:141)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
>         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.wsf.container.jboss50.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:104)
>         at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:220)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 08:01:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 22 Aug 2007 08:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4620) NPE in EJB3
 Authentication Interceptor
In-Reply-To: <12500267.1187782938496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31655768.1187784078305.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf updated JBAS-4620:
--------------------------------

    Component/s: EJB3
       Priority: Blocker  (was: Major)

> NPE in EJB3 Authentication Interceptor
> --------------------------------------
>
>                 Key: JBAS-4620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Thomas Diesler
>         Assigned To: Anil Saldhana
>            Priority: Blocker
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Most EJB3 web service tests fail because of 
> java.lang.NullPointerException
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:141)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
>         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.wsf.container.jboss50.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:104)
>         at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:220)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 08:03:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11221606.1187784198294.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373293 ] 
            
Edson Tirelli commented on JBRULES-1065:
----------------------------------------

Michael,

What the user is asking for is auto-vivification for "variable restrictions". We already have that for return value restrictions and inline-evals. I think we should add this "syntax-sugar", since Tong is not the only user to request that.
But you are right, this is not a bug per se, and all following approaches already work:

$record : Record( abc == $record.xyz ) 
Record( abc == this.xyz )
Record( xyz : xyz, abc == xyz )

I will look into allowing that today.

Edson

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 08:39:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32356760.1187786358268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373297 ] 
            
Edson Tirelli commented on JBRULES-1065:
----------------------------------------

Michael just told me that the following is not working, so I need to fix it.

Record( abc == this.xyz ) 

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 08:50:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1089) Getting "could
 not access property ('=')" for a valid rule.
In-Reply-To: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33163165.1187787018748.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1089?page=comments#action_12373298 ] 
            
Edson Tirelli commented on JBRULES-1089:
----------------------------------------

This problem is fixed in drools-compiler, but we still depend on mvel fixing:

http://jira.codehaus.org/browse/MVEL-29
http://jira.codehaus.org/browse/MVEL-30

As soon as it is done, I will close this ticket.


> Getting "could not access property ('=')" for a valid rule.
> -----------------------------------------------------------
>
>                 Key: JBRULES-1089
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
>            Reporter: Arsalan Zaidi
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
> Sent: 13 August 2007 22:16
> To: Rules Users List
> Subject: Re: [rules-users] could not access property ('=')
> Attachments: ATT426765.txt
>    This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?
>    Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 
> when
>            $dto : DTO( )
>            W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1
> then
>    Thanks, and hope it helps.
>    Edson
> 2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
>   Hi.
>   I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.
>   I have a rule which looks like this:
>   rule "W250.42 Editable"
>         when
>               DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )
>         then
>               System.out.println ("0" );
>               Action action = createAction("W250.42" , false , true );
>               retList.add(action); 
>   end 
>   both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .
>   Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.
>   org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )
>         at org.drools.reteoo.Rete.assertObject(Rete.java:168 )
>         at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 
>         at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )
>         at com.sample.DroolsTest.main( DroolsTest.java:34)
>   Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )
>         at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )
>         at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )
>         at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)
>         at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 
>         at org.mvel.MVEL.executeExpression( MVEL.java:202)
>         at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )
>         ... 10 more
>   Caused by: org.mvel.PropertyAccessException: could not access property ('=') 
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )
>         ... 18 more
>   If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.
>   I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')
>   What seems to be the issue?
>   Thanks in advance!
>   Regards,
>   --Arsalan
>         This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 
>        
>   _______________________________________________
>   rules-users mailing list
>   rules-users at lists.jboss.org 
>   https://lists.jboss.org/mailman/listinfo/rules-users
> -- 
>   Edson Tirelli
>   Software Engineer - JBoss Rules Core Developer
>   Office: +55 11 3529-6000
>   Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat @ www.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 lists.jboss.org  Wed Aug 22 08:52:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1047) class Cast
 Exception when using OR (||)
In-Reply-To: <20755281.1185814069735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22218134.1187787138411.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1047.
----------------------------------

    Resolution: Done

As I received no further info on this, I'm closing it. If the problem persists, please reopen it.


> class Cast Exception when using OR (||)
> ---------------------------------------
>
>                 Key: JBRULES-1047
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1047
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows, X86
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> When I define a rule:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct, 
>                active:active==$1,
>                relationName=="Old")
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ..The bove works. 
> BUT, when I do the following:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> || Relation( contact==cntct, 
>                active:active==$1,
>                relationName==null)
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ... The script compiles anda stateless Session is created successfully, 
> but at 
> runtime/execution it fails with the exception:
> java.lang.ClassCastException: com.arjun.brms.businessObjects.Contact
> org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:75)
> org.drools.reteoo.EvalConditionNode.assertTuple (EvalConditionNode.java:141)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple 
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:317)
> org.drools.reteoo.AlphaNode.assertObject (AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject 
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> org.drools.reteoo.Rete.assertObject(Rete.java:168)
> org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java :190)
> org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java :822)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> Class diagram:
> ~~~~~~~~~~~~~~~~
> Contact<-- bi-directional association -->List<Relation>
> =============================================================================
> Edson comments (Response) :
> -----------------------------------------
> It is a bug since a more friendly message should be raised at compile time stating that your "contact" declaration is not available in one of your logical branches. 
>     Having said that, what you want to do is make your OR take priority over the implicit AND and as such, you need to add () around the OR: 
> When
> contact:Contact (initialized==true)
> exr: ( Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> or Relation( contact==cntct,
>                active:active==$1, 
>                relationName==null) )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    Having said that, better yet for you would not to use the OR CE, but to use restriction connectives. This would be the most efficient (and clean) way of writing your rule: 
> When
> contact:Contact (initialized==true)
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName =="Old" || == null )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    As a syntax sugar, you could also write:
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName in ( "Old", null ) )
>    Can you please open a JIRA with your test case for the bug? 
>    Thank you,
>         Edson
> -------------------
> Note: The above suggestion worked, no runtime errors with 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 lists.jboss.org  Wed Aug 22 08:56:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1074) Support the use
 of Integer, Float, Short and Byte in accumulate functions
In-Reply-To: <14718682.1186924981314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1599861.1187787378509.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1074:
-----------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

Expression type is currently managed by MVEL. We need to define a long term solution for this, so I'm moving this ticket to FUTURE.

> Support the use of Integer, Float, Short and Byte in accumulate functions
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1074
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1074
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: FUTURE
>
>
> Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 09:10:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 09:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
In-Reply-To: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8961340.1187788219023.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1058.
----------------------------------

    Resolution: Duplicate Issue

This is being handled as part of http://jira.jboss.com/jira/browse/JBRULES-1089

> nested accessors with Sets - "not contains" is not a valid operator for MVEL
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-1058
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark McNally
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Following does not work:
> 		rule StateMatch
> 			when
> 			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
> 			then 	
> 				retract( $ca );
> 		end
> 		
> 		
> 		public class CandidateAssociation {
> 			private PatientDetails patientDetails;
> 			private NurseDetails   nurseDetails;
> 			private int overlapHours;
> 		
> 			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
> 				super();
> 				this.patientDetails = patientDetails;
> 				this.nurseDetails = nurseDetails;
> 				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
> 			}
> 		    [...]
> 		}
> 		
> 		public class NurseDetails {
> 			private Set stateLicensures = new HashSet();
> 			[...]
> 		}
> 		public class PatientDetails {
> 			private String state;
> 			[...]
> 		}
> Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 
> Also Noticed that the following workaround did not work:
> 		rule State
> 		    dialect "mvel"
> 			when
> 		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
> 			then 	
> 		  	    retract( $ca );
> 		end
> 		
> 		This produced this Exception:
> 		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
> 	        at org.drools.rule.Package.checkValidity(Package.java:408)
> 	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	        at [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 09:12:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 09:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28239360.1187788338327.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1091:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 09:15:51 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Aug 2007 09:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-203) Primary Partiton
 approach for handling of partitions
Message-ID: <13189356.1187788551148.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I don't see why PRIMARY_PARTITION needs to sort the MergeView is receives: a MergeView is only created by the *merge leader*, and therefore it will be exactly the same on all merge cordinators.
So we don't need to sort it.
A much simpler implementation could be to deterministically find out the primary partition and then send EXIT events to all members in non-primary partitions.
Even simpler: there could be an option in JChannel that triggers an EXIT if we're not in the primary partition on reception of a MergeView. User code could be called to determine the primary partition

> Primary Partiton approach for handling of partitions
> ----------------------------------------------------
>
>                 Key: JGRP-203
>                 URL: http://jira.jboss.com/jira/browse/JGRP-203
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: PRIMARY_PARTITION.java
>
>
> Add this approach to JGroups. Members in a non-primary partition will shut down, become read-only etc.
> Google for "primary partition AND group communication" for the relevant literature on 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 lists.jboss.org  Wed Aug 22 09:51:22 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Wed, 22 Aug 2007 09:51:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1646) portal-cms
 depends on existence of user 'admin'
Message-ID: <23503800.1187790682411.JavaMail.jira@cloud.prod.atl2.jboss.com>

portal-cms depends on existence of user 'admin'
-----------------------------------------------

                 Key: JBPORTAL-1646
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1646
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.6.1 Final
            Reporter: Tobias Roth
         Assigned To: Sohil Shah


cms/src/main/org/jboss/portal/cms/impl/jcr/JCRCMS.java has the user 'admin' hardcoded:


   /** Loads content from sar and adds it to the repo. */
   public void createContent() throws Exception
   {
      log.info("Creating default CMS content.");
      

      // Get the content
      URL root = Thread.currentThread().getContextClassLoader().getResource(defaultContentLocation);

      
      //make the user executing these to create the default content, an 'Admin' user
      //without this, the fine grained security won't allow the creation
      UserModule userModule = getUserModule();
      if(userModule != null)
      {
	      org.hibernate.Session session = org.jboss.portal.cms.hibernate.state.Tools.getOpenSession();
	      org.hibernate.Transaction tx = session.beginTransaction();
	      User user = userModule.findUserByUserName("admin"); // HERE
	      if(user!=null)
	      {
	    	  JCRCMS.getUserInfo().set(user);
	      }
	      tx.rollback();
	      org.jboss.portal.cms.hibernate.state.Tools.closeSession(session);
      }	


If it doesn't exist (for example because LDAP is being used), portal-cms cannopt be deployed, and several database tables are not created. If 'admin' is changed to an existing user, everything works fine.

There is another reference to 'admin' in cms/src/main/org/jboss/portal/cms/impl/jcr/command/ACLEnforcer.java, but leaving this as it is doesn't seem to have any negative 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 lists.jboss.org  Wed Aug 22 10:45:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 10:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-259) Migrate AOP builds
	to maven
Message-ID: <18720598.1187793918279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-259?page=all ]

Paul Gier updated JBBUILD-259:
------------------------------

    Summary: Migrate AOP builds to maven  (was: AOP pom)

> Migrate AOP builds to maven
> ---------------------------
>
>                 Key: JBBUILD-259
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-259
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>          Time Spent: 1 day
>  Remaining Estimate: 3 days
>
> Migrate AOP builds to maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 11:20:18 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 22 Aug 2007 11:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1045) test suite has to
 trow a runtime exception on error so meaningful report is generated
Message-ID: <1738376.1187796018337.JavaMail.jira@cloud.prod.atl2.jboss.com>

test suite has to trow a runtime exception on error so meaningful report is generated
-------------------------------------------------------------------------------------

                 Key: JBPM-1045
                 URL: http://jira.jboss.com/jira/browse/JBPM-1045
             Project: JBoss jBPM
          Issue Type: Bug
    Affects Versions: jBPM jPDL 3.2.2
            Reporter: Aleksandar Kostadinov
         Assigned To: Tom Baeyens


When there are test suite initialization problems, test suite ignores exception (just prints it to the output) that causes junit to crash. 

I identified the issue in the following files:

jpdl/jar/src/test/java/org/jbpm/AllDBTests.java
jpdl/jar/src/test/java/org/jbpm/AllTests.java
have to have "throw t;" after "t.printStackTrace();"

As well the following test cases seem suspicious to me. I mean I'm not sure if an exception by these tests will cause a test suite crash. Please inspect if trowing an axception is desirable after printStackTrace method is used in these files:
./msg/command/AsyncExecutionDbTest.java
./perf/MemLeakTest.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 lists.jboss.org  Wed Aug 22 11:26:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 11:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18010504.1187796378850.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1055?page=comments#action_12373328 ] 
            
Edson Tirelli commented on JBRULES-1055:
----------------------------------------

This is actually a documentation problem and not a bug. DSL was augmented in Drools 4.0 to support regexps as part of the mappings. This intents to make DSL mappings more robust and allowing users to handle more situations with less effort. For instance, if you want to handle multiple values, you could write a mapping like:

[when][]Customer code is [ABCD]=Customer( code == "premium")

The above mapping will match any of the following statements:

Customer code is A
Customer code is B
Customer code is C
Customer code is D

As [ABCD] is interpreted as a regexp.

So, in your case, the only fix you need to do is escape your [] in the same way you escape them in regular expressions. Look at the following example:

[when][]attr {attr_name} is in \[ {values} \]={attr_name} in ( {values} )

The above mapping will match:

attr name is in [ 'Edson', 'Bob' ]

And translate that into:

name in ( 'Edson', 'Bob' )

I will look at fixing documentation. This is not backward compatible, but we feel the added flexibility was worth breaking the compatibility in the major version release.


> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 11:59:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 11:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8419534.1187798358222.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Assignee:     (was: Carlo de Wolf)

Is this the latest version we can use?

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:01:28 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:01:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4568) AOP 2.0.0.beta
In-Reply-To: <31447129.1184845427146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3391727.1187798488015.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Is 2.2.0.beta still the target AOP release? (currently on snapshot)

> AOP 2.0.0.beta
> --------------
>
>                 Key: JBAS-4568
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4568
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: AOP
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:01:28 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:01:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4392) Replace j2ee and
 ejb3x module with javaee module
In-Reply-To: <14393824.1178194240545.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29185819.1187798488707.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Is there more work to it?

> Replace j2ee and ejb3x module with javaee module
> ------------------------------------------------
>
>                 Key: JBAS-4392
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4392
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:01:28 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 12:01:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
In-Reply-To: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24599972.1187798488841.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-403?page=all ]

Paul Gier reassigned JBBUILD-403:
---------------------------------

    Assignee: Paul Gier

> Add config parameter to specify groupId in jboss deploy plugin
> --------------------------------------------------------------
>
>                 Key: JBBUILD-403
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-deploy-plugin
>    Affects Versions: maven-jboss-deploy-plugin-1.3
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:03:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2853) Integrate JBoss
 Cache 2.0 into AS 5.0
Message-ID: <22950696.1187798598321.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I see the trunk moved to 2.0.0.GA.

Are we updating JGroups, too? (2.5)

> Integrate JBoss Cache 2.0 into AS 5.0
> -------------------------------------
>
>                 Key: JBAS-2853
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2853
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBoss Cache
>            Reporter: Manik Surtani
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> JBC 2.0.0.ALPHA1 was produced for JB5, Beta1.
> I'm assigning this issue to the next beta, to track further integration 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 lists.jboss.org  Wed Aug 22 12:03:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19938937.1187798598452.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Is the target 2.1.0 or 2.0.1 ?

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:14:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 12:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
In-Reply-To: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17580067.1187799258304.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-403?page=all ]

Paul Gier closed JBBUILD-403.
-----------------------------

    Resolution: Done

Added a groupId parameter.

> Add config parameter to specify groupId in jboss deploy plugin
> --------------------------------------------------------------
>
>                 Key: JBBUILD-403
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-deploy-plugin
>    Affects Versions: maven-jboss-deploy-plugin-1.3
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:16:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Aug 2007 12:16:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2853) Integrate JBoss
 Cache 2.0 into AS 5.0
Message-ID: <24662415.1187799379910.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I have to sort it out with Tim Fox, i.e. get consensus on adding it to the JBM component-info.xml. Otherwise build breaks. We chatted a bit about that around beg of July, but it got somewhat sidetracked with some discussion about JBM in 4.2. ;)  I'll ping him again.

> Integrate JBoss Cache 2.0 into AS 5.0
> -------------------------------------
>
>                 Key: JBAS-2853
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2853
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBoss Cache
>            Reporter: Manik Surtani
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> JBC 2.0.0.ALPHA1 was produced for JB5, Beta1.
> I'm assigning this issue to the next beta, to track further integration 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 lists.jboss.org  Wed Aug 22 12:16:20 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 12:16:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-406) Create retro
	build for aop
In-Reply-To: <1127269.1187729719337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3103798.1187799380172.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-406?page=all ]

Paul Gier reassigned JBBUILD-406:
---------------------------------

    Assignee: Paul Gier

> Create retro build for aop
> --------------------------
>
>                 Key: JBBUILD-406
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-406
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> AOP needs a retro 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 lists.jboss.org  Wed Aug 22 12:24:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 12:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27531961.1187799858450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373341 ] 
            
Edson Tirelli commented on JBRULES-1091:
----------------------------------------

Not sure what we can do about this, since a null value is not a valid "fact" for the engine, and as such, it can't reason over it...

Anyone want to suggest something?


> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 12:33:36 2007
From: jira-events at lists.jboss.org (davide pasinato (JIRA))
Date: Wed, 22 Aug 2007 12:33:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4621) error deploying
 admin-consoles in deploy is a link
Message-ID: <10186901.1187800416294.JavaMail.jira@cloud.prod.atl2.jboss.com>

error deploying admin-consoles in deploy is a link
--------------------------------------------------

                 Key: JBAS-4621
                 URL: http://jira.jboss.com/jira/browse/JBAS-4621
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Console
    Affects Versions: JBossAS-4.2.1.GA
         Environment: linux RH-4 Sun jdk 1.5 jboss 4.2.1 server: all with jbossws-2.0.1
            Reporter: davide pasinato
         Assigned To: Darran Lofthouse
            Priority: Minor


I have a cluster of two jboss 4.2.1 servers. They run on the same machine. For this reason the server B links the directories deploy and lib of the server A when I start server A everything run smoothly. When I start server B I get an exception deploying the administration consoles. Looks like the directory management doesnt like symbolic links. 

This is the exception I get on server B (the root directory of server B is /var/opt/jboss/stress1b):

org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute at e5f0d2 on mbean jboss.admin:service=DeploymentFileRepository; - nested throwable: (java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b')
        at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:698)
        at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:332)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
        at org.jboss.system.ServiceController.install(ServiceController.java:226)
        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.install(Unknown Source)
        at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
        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 $Proxy9.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.GeneratedMethodAccessor4.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.GeneratedMethodAccessor10.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:508)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b'
        at org.jboss.console.manager.DeploymentFileRepository.getFile(DeploymentFileRepository.java:151)
        at org.jboss.console.manager.DeploymentFileRepository.setBaseDir(DeploymentFileRepository.java:124)
        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.AttributeDispatcher.invoke(AttributeDispatcher.java:136)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:103)
        at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
        at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608)
        at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:694)
        ... 84 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 lists.jboss.org  Wed Aug 22 12:46:18 2007
From: jira-events at lists.jboss.org (davide pasinato (JIRA))
Date: Wed, 22 Aug 2007 12:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4621) error deploying
 admin-consoles in deploy is a link
In-Reply-To: <10186901.1187800416294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20634104.1187801178571.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

davide pasinato updated JBAS-4621:
----------------------------------


To better explain my enviroment (to help you to reproduce my problem) this is the structure of my server B

ls /var/opt/jboss/stress1b

conf -> ../stress1a/conf
data
deploy -> ../stress1a/deploy
farm
lib -> ../stress1a/lib
log
tmp
work

while server A is a standard server whose server root directory is /var/opt/jboss/stress1a

> error deploying admin-consoles in deploy is a link
> --------------------------------------------------
>
>                 Key: JBAS-4621
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4621
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.2.1.GA
>         Environment: linux RH-4 Sun jdk 1.5 jboss 4.2.1 server: all with jbossws-2.0.1
>            Reporter: davide pasinato
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>
> I have a cluster of two jboss 4.2.1 servers. They run on the same machine. For this reason the server B links the directories deploy and lib of the server A when I start server A everything run smoothly. When I start server B I get an exception deploying the administration consoles. Looks like the directory management doesnt like symbolic links. 
> This is the exception I get on server B (the root directory of server B is /var/opt/jboss/stress1b):
> org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute at e5f0d2 on mbean jboss.admin:service=DeploymentFileRepository; - nested throwable: (java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b')
>         at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:698)
>         at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:332)
>         at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>         at org.jboss.system.ServiceController.install(ServiceController.java:226)
>         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.install(Unknown Source)
>         at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
>         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 $Proxy9.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.GeneratedMethodAccessor4.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.GeneratedMethodAccessor10.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:508)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b'
>         at org.jboss.console.manager.DeploymentFileRepository.getFile(DeploymentFileRepository.java:151)
>         at org.jboss.console.manager.DeploymentFileRepository.setBaseDir(DeploymentFileRepository.java:124)
>         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.AttributeDispatcher.invoke(AttributeDispatcher.java:136)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:103)
>         at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
>         at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608)
>         at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:694)
>         ... 84 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 lists.jboss.org  Wed Aug 22 12:54:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 22 Aug 2007 12:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4568) AOP 2.0.0.beta
In-Reply-To: <31447129.1184845427146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16275349.1187801658239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4568?page=comments#action_12373353 ] 
            
Kabir Khan commented on JBAS-4568:
----------------------------------

Yes, and we'll get the beta out

> AOP 2.0.0.beta
> --------------
>
>                 Key: JBAS-4568
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4568
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: AOP
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 13:14:18 2007
From: jira-events at lists.jboss.org (=?UTF-8?Q?Jacques_Desmazi=EF=BF=A8res_=28JIRA=29?=)
Date: Wed, 22 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1046) JobExecutorServlet
 cannot use local JNDI name to access fatasource
Message-ID: <10473705.1187802858662.JavaMail.jira@cloud.prod.atl2.jboss.com>

JobExecutorServlet cannot use local JNDI name to access fatasource
------------------------------------------------------------------

                 Key: JBPM-1046
                 URL: http://jira.jboss.com/jira/browse/JBPM-1046
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: Windows 2000
IBM Websphere Application Server 6.1 (also reproduced on Websphere Test Environment 5.1)
Oracle 9i database (with ojdbc14.jar release 9.2.0.8)

            Reporter: Jacques Desmazi?res
         Assigned To: Tom Baeyens
             Fix For:  jBPM jPDL 3.2.1


When configuraing jBPM / Hibernate with a datasource in an Enterprise application, using a local JNDI reference (java:comp/env/...) the web application works properly, accessing the database without any problem. 

But if you declare the JobExecutorServlet in the web application's web.xml, each time the this servlet JobExecutorThread fires, it generates exceptions:

[22/08/07 18:33:03:175 CEST] 0000005e SystemOut     O 18:33:03 DEBUG org.jbpm.job.executor.JobExecutorThread : acquiring jobs for execution...
[22/08/07 18:33:03:315 CEST] 0000005f javaURLContex E   NMSV0310E: Une op?ration JNDI sur un nom "java:" ne peut pas aboutir car le contexte d'ex?cution du serveur ne peut pas associer l'unit? d'ex?cution de l'op?ration ? un composant d'application J2EE. Cette condition peut se produire lorsque le client JNDI utilisant le nom "java:" n'est pas ex?cut? sur l'unit? d'ex?cution d'une demande d'application du serveur. Assurez-vous qu'une application J2EE n'ex?cute pas d'op?rations JNDI sur des noms "java:" dans des blocs de code statiques ou dans des unit?s d'ex?cution cr??es par cette application J2EE. Un code de ce type ne s'ex?cute pas n?cessairement sur l'unit? d'ex?cution d'une demande d'application du serveur et n'est donc pas pris en charge par les op?rations JNDI sur les noms "java:". Trace de pile d'exceptions : 
javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
	at javax.naming.InitialContext.lookup(InitialContext.java:363)
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
Caused by: javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
	... 17 more
 
[22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 FATAL org.hibernate.connection.DatasourceConnectionProvider : Could not find datasource: java:comp/env/jdbc/dsJBPM
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
	at javax.naming.InitialContext.lookup(InitialContext.java:363)
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
Caused by: 
javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
	... 17 more
[22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 ERROR org.jbpm.job.executor.JobExecutorThread : exception in job executor thread. waiting 10000 milliseconds
org.hibernate.HibernateException: Could not find datasource
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:56)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
Caused by: 
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
	at javax.naming.InitialContext.lookup(InitialContext.java:363)
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
	... 13 more
Caused by: 
javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
	... 17 more

The exception is raised even if there is no timer in the process definition.

If I replace the local JNDI reference (java:comp/env/jdbc/datasource) with the global JNDI name (jdbc/dsOracle) the JobExecutorThread works fine (even if Websphere logs warning due to direct use of the global JNDI reference). The JobExecutorThread also works if I replace the datasource with the database access parameters (driver, url, ...).


(sample ear is available to reproduce the bug if 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 lists.jboss.org  Wed Aug 22 13:30:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Wed, 22 Aug 2007 13:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1110) Rules with 'From'
 condition with another not using From causes problem
Message-ID: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rules with 'From' condition with another not using From causes problem
----------------------------------------------------------------------

                 Key: JBRULES-1110
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Decision tables, Reteoo
    Affects Versions:  4.0.0.GA
         Environment: Any
            Reporter: Arjun Dhar
         Assigned To: Mark Proctor


Test case:

Write a Rule that uses a From clause and on another object does not use a from clause:
example:
#From row number: 28
rule "Rules_28"
	
	when
		cntct: Contact(initialized==true)
		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
	then
                             System.out.println("Fired 28");
end

If All 3 are true:
 1. Delete Condition 2 --> Rule fires
 2. Delete COnditon 3 (But keep 2) --> Rule fires
 3. Keep 2 & 3 (with 1) --> Rule does not fire

Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.

Please see if it is 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 lists.jboss.org  Wed Aug 22 13:32:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Wed, 22 Aug 2007 13:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
Message-ID: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>

Final methods of POJO's aer never evaluated
-------------------------------------------

                 Key: JBRULES-1111
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Arjun Dhar
         Assigned To: Mark Proctor
            Priority: Minor


If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 13:50:33 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 22 Aug 2007 13:50:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-75)
 SecurityAssociation on the Client Side
Message-ID: <24127516.1187805033678.JavaMail.jira@cloud.prod.atl2.jboss.com>

SecurityAssociation on the Client Side
--------------------------------------

                 Key: SECURITY-75
                 URL: http://jira.jboss.com/jira/browse/SECURITY-75
             Project: JBoss Security and Identity Management
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0.1-BETA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1-GA


Clients may have done deeper integration with security association (in lieu of JAAS).  The principal/credential needs to be transferred into a 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 lists.jboss.org  Wed Aug 22 13:52:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 13:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18391261.1187805138378.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1055.
----------------------------------

    Resolution: Done

I added a note on the Upgrade Tips section about DSL and unit tests just to make sure it was working.
The chapter on DSL still needs to be rewritten though.


> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 13:52:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 22 Aug 2007 13:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-75) SecurityAssociation
 on the Client Side
In-Reply-To: <24127516.1187805033678.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28729716.1187805138497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-75?page=all ]

Anil Saldhana closed SECURITY-75.
---------------------------------

    Resolution: Done

Running org.jboss.test.securityassociation.LegacySecurityAssociationTestCase
Found log4j.xml: file:/C:/cygwin/home/asaldhana/security/security-jboss-sx/trunk
/target/test-classes/log4j.xml
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 sec

> SecurityAssociation on the Client Side
> --------------------------------------
>
>                 Key: SECURITY-75
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-75
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.1-BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1-GA
>
>
> Clients may have done deeper integration with security association (in lieu of JAAS).  The principal/credential needs to be transferred into a 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 lists.jboss.org  Wed Aug 22 14:20:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Wed, 22 Aug 2007 14:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8242477.1187806818210.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4563?page=comments#action_12373366 ] 
            
Emmanuel Bernard commented on JBAS-4563:
----------------------------------------

No the latest version is 3.3.0
3.3.1 is due as soon as I have some spare time and is mostly bug fixing.
http://opensource.atlassian.com/projects/hibernate/browse/ANN?report=com.atlassian.jira.plugin.system.project:roadmap-panel

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:04:18 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 22 Aug 2007 15:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1045) test suite has to
 trow a runtime exception on error so meaningful report is generated
In-Reply-To: <1738376.1187796018337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23722263.1187809458294.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1045?page=comments#action_12373378 ] 
            
Aleksandar Kostadinov commented on JBPM-1045:
---------------------------------------------

--- AllTests    2007-08-22 14:50:04.713887000 -0400
+++ AllTests.java       2007-08-22 14:57:25.335824000 -0400
@@ -36,7 +36,8 @@
       return suite;
     } catch (Throwable t) {
       t.printStackTrace();
-      return null;
+      throw new RuntimeException(t);
+      // return null;
     }
   }
 }

--- AllDbTests  2007-08-22 15:02:04.809038000 -0400
+++ AllDbTests.java     2007-08-21 10:18:22.329696000 -0400
@@ -84,6 +84,7 @@

     } catch (Throwable t) {
       t.printStackTrace();
+      throw new RuntimeException(t);
     }

Let me not give blind suggestions about both the other 2 files. Haven't looked into do code. These are lower priority.

> test suite has to trow a runtime exception on error so meaningful report is generated
> -------------------------------------------------------------------------------------
>
>                 Key: JBPM-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1045
>             Project: JBoss jBPM
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL 3.2.2
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Tom Baeyens
>
> When there are test suite initialization problems, test suite ignores exception (just prints it to the output) that causes junit to crash. 
> I identified the issue in the following files:
> jpdl/jar/src/test/java/org/jbpm/AllDBTests.java
> jpdl/jar/src/test/java/org/jbpm/AllTests.java
> have to have "throw t;" after "t.printStackTrace();"
> As well the following test cases seem suspicious to me. I mean I'm not sure if an exception by these tests will cause a test suite crash. Please inspect if trowing an axception is desirable after printStackTrace method is used in these files:
> ./msg/command/AsyncExecutionDbTest.java
> ./perf/MemLeakTest.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 lists.jboss.org  Wed Aug 22 15:28:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 15:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1065) Unable to return
 Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21937175.1187810898471.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1065.
----------------------------------

    Resolution: Done

Added support for autovivification in variable restrictions. This is now working:

rule "autovivification"
when
     Cheese( price > oldPrice, price > this.oldPrice )
then
     results.add( "OK" );
end

Integration test added. 

Thanks for reporting.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 15:30:22 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 15:30:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24073088.1187811022902.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1101?page=comments#action_12373382 ] 
            
Edson Tirelli commented on JBRULES-1101:
----------------------------------------

I did a few changes that may solve the problem as part of http://jira.jboss.com/jira/browse/JBRULES-1065. 
I'm closing the ticket. If the problem persists, please re-open the ticket and attach a sample rule.

Thanks for reporting.

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:30:23 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 15:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15775040.1187811023147.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1101.
----------------------------------

    Resolution: Done

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:34:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Aug 2007 15:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4622) Can't flush bad
 naming stub if no java.naming.provider.url specified
Message-ID: <5212830.1187811258275.JavaMail.jira@cloud.prod.atl2.jboss.com>

Can't flush bad naming stub if no java.naming.provider.url specified
--------------------------------------------------------------------

                 Key: JBAS-4622
                 URL: http://jira.jboss.com/jira/browse/JBAS-4622
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3


The NamingContext class maintains a static cache of server-side naming stubs, keyed by the address:port of the server.  Entries from this cache are meant to be removed if an IOException is caught when invoking on the stub, thus ensuring that problem stubs are discarded and a new stub lookup is forced.

This cache clearing process breaks if java.naming.provider.url is not set.  The clearing algorithm is in NamingContext.removeServer(Hashtable) is a no-op if the naming environment does not include java.naming.provider.url.  Based on a comment on the method, the reasoning behind this is to avoid flushing the "local" (i.e. in-vm) server from the cache.  But, the way the naming acquisition process works, a direct ref to the in-vm server will never be stored in the cache anyway, so this distinction in not valid.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:41:25 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 22 Aug 2007 15:41:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
In-Reply-To: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26293061.1187811685862.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1164?page=comments#action_12373389 ] 
            
Manik Surtani commented on JBCACHE-1164:
----------------------------------------

Does this exist in 2.0.0.GA as well?

> NodeNotExistException with concurent put/remove operations
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1164
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: ConcurentOperationsTest.java
>
>
> When 2 Threads are putting/removing data from this same node, put operation fails with exception
> org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
> 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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
> 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:89) 
> 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) 
> (...) 
> Thread 1 is calling: 
> 	cache.remove("/a/b/c/d");
> 	cache.remove("/a");
>  Thread 2 is calling: 
> 	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Wed Aug 22 15:41:26 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 22 Aug 2007 15:41:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1166)
 UpgradeException on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12051884.1187811686117.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=comments#action_12373390 ] 
            
Manik Surtani commented on JBCACHE-1166:
----------------------------------------

Is this just a PojoCache bug?  What happens with core cache in this case?

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Wed Aug 22 16:20:18 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Wed, 22 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31795580.1187814018319.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373396 ] 
            
Alexandre Gattiker commented on JBRULES-1091:
---------------------------------------------

The intent of the actual business rule that spawned the bug was to use Drools to perform aggregation, in a similar way to a SQL query. Something like

when
$c:Customer()
$totalPayments:Money()
   from accumulate( Payment ( customer == $c) ...
then
  ...do something with $totalPayments...

The result can be null. Obviously, using Drools syntax rather than collecting Payments in the RHS is mostly a convenience (though it might bring a performance boost in some cases).

The bug can be resolved easily by handling the null value in the hashCode call in DefaultFactHandle. But I assume that you worry about the case when constraints are placed on the accumulated value.

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 16:24:29 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Wed, 22 Aug 2007 16:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
In-Reply-To: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26044471.1187814269909.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1164?page=comments#action_12373397 ] 
            
Jacek Halat commented on JBCACHE-1164:
--------------------------------------

yes, this exists in 2.0.0 GA, but because put/remove operations are replaced with attach/detach and in 2.0.0 GA another exception is thrown (UpgradeException) another issue was created (JBCACHE-1164). (Probably this is this same bug but exception for user is another)

> NodeNotExistException with concurent put/remove operations
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1164
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: ConcurentOperationsTest.java
>
>
> When 2 Threads are putting/removing data from this same node, put operation fails with exception
> org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
> 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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
> 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:89) 
> 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) 
> (...) 
> Thread 1 is calling: 
> 	cache.remove("/a/b/c/d");
> 	cache.remove("/a");
>  Thread 2 is calling: 
> 	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Wed Aug 22 16:36:29 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 22 Aug 2007 16:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1035) get latest
	tutorials online
Message-ID: <18674529.1187814989070.JavaMail.jira@cloud.prod.atl2.jboss.com>

get latest tutorials online
---------------------------

                 Key: EJBTHREE-1035
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1035
             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 lists.jboss.org  Wed Aug 22 16:38:18 2007
From: jira-events at lists.jboss.org (krish p (JIRA))
Date: Wed, 22 Aug 2007 16:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1279) shutdown -u -p
 options are not working
Message-ID: <17580009.1187815098802.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1279?page=comments#action_12373400 ] 
            
krish p commented on JBAS-1279:
-------------------------------

Is this fixed in 4.0.5? I see this issue when JBoss Portal 2.6 is deployed in JBoss and I try running "shutdown.sh -S -u admin". I've used a custom security realm and updated jmx-invoker-service.xml accordingly.

> shutdown -u -p options are not working
> --------------------------------------
>
>                 Key: JBAS-1279
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1279
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Wonne Keysers
>         Assigned To: Scott M Stark
>             Fix For:  JBossAS-4.0.2RC1
>
>
> This feature does work in 3.2.x, but is apparently not yet implemented in 4.0.1 ?
> Unable to shutdown the server when the following is commented out in jmx-invoker-service.xml:
> <descriptors>
>    <interceptors>
> 	  <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
> 		 securityDomain="java:/jaas/jmx-console"/>
>    </interceptors>
> </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 lists.jboss.org  Wed Aug 22 16:47:21 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Wed, 22 Aug 2007 16:47:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1166)
 UpgradeException on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4642714.1187815641558.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=comments#action_12373401 ] 
            
Jacek Halat commented on JBCACHE-1166:
--------------------------------------

Stack trace for core cache:

org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/a/b/c/d, caller=GlobalTransaction:<null>:4, lock=write owner=GlobalTransaction:<null>:3 (activeReaders=0, activeWriter=Thread[Thread-2,5,main], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:528)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1581)
	at org.jboss.cache.aop.ConcurentOperationTestPojo$WorkThread.run(ConcurentOperationTestPojo.java:83)
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /a/b/c/d could not be acquired after 10000 ms. Locks: Read lock owners: []
Write lock owner: GlobalTransaction:<null>:3
 (caller=GlobalTransaction:<null>:4, lock info: write owner=GlobalTransaction:<null>:3 (activeReaders=0, activeWriter=Thread[Thread-2,5,main], waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:244)
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
	... 17 more



> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java, ConcurentOperationTestCore.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Wed Aug 22 16:47:21 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Wed, 22 Aug 2007 16:47:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7875992.1187815641763.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=all ]

Jacek Halat updated JBCACHE-1166:
---------------------------------

    Attachment: ConcurentOperationTestCore.java

Test for core cache

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java, ConcurentOperationTestCore.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Wed Aug 22 16:54:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 16:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31495300.1187816058379.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373405 ] 
            
Edson Tirelli commented on JBRULES-1091:
----------------------------------------

Alexander,

Yes, the problem is exactly further constraints on the null value.

I understand that in sql the result could be null, but in drools, it should only be null if the user does it on purpose, what would be wrong. Such accumulations are always initialized in the init block:

when
$c:Customer()
$totalPayments:Money()
   from accumulate( Payment ( customer == $c, $val : value )
                                   init( Money total = new Money( 0 ); )
                                   action( total.add( $val ); )
                                   reverse( total.subtract( $val ); )
                                   result( total ) )
then 
   // ...
end

Is my assumption wrong?

So, maybe we can add a null check, so that we can provide a user friendly error message, but allowing null into the engine has huge drawbacks.

On an unrelated note, did you saw the accumulate functions feature? It may be interesting for you, doing things like:

when
$c:Customer()
$totalPayments:Number()
   from accumulate( Payment ( customer == $c, $val : value )
                                   sum( $val ) )
then 
   // ...
end

You can also create your own functions in case you want to return custom objects like the Money object in your example.



> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 17:13:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 17:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1089) Getting "could not
 access property ('=')" for a valid rule.
In-Reply-To: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18400973.1187817198411.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1089.
----------------------------------

    Resolution: Done

MVEL is fixed, so closing the ticket.

> Getting "could not access property ('=')" for a valid rule.
> -----------------------------------------------------------
>
>                 Key: JBRULES-1089
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
>            Reporter: Arsalan Zaidi
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
> Sent: 13 August 2007 22:16
> To: Rules Users List
> Subject: Re: [rules-users] could not access property ('=')
> Attachments: ATT426765.txt
>    This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?
>    Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 
> when
>            $dto : DTO( )
>            W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1
> then
>    Thanks, and hope it helps.
>    Edson
> 2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
>   Hi.
>   I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.
>   I have a rule which looks like this:
>   rule "W250.42 Editable"
>         when
>               DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )
>         then
>               System.out.println ("0" );
>               Action action = createAction("W250.42" , false , true );
>               retList.add(action); 
>   end 
>   both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .
>   Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.
>   org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )
>         at org.drools.reteoo.Rete.assertObject(Rete.java:168 )
>         at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 
>         at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )
>         at com.sample.DroolsTest.main( DroolsTest.java:34)
>   Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )
>         at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )
>         at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )
>         at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)
>         at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 
>         at org.mvel.MVEL.executeExpression( MVEL.java:202)
>         at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )
>         ... 10 more
>   Caused by: org.mvel.PropertyAccessException: could not access property ('=') 
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )
>         ... 18 more
>   If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.
>   I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')
>   What seems to be the issue?
>   Thanks in advance!
>   Regards,
>   --Arsalan
>         This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 
>        
>   _______________________________________________
>   rules-users mailing list
>   rules-users at lists.jboss.org 
>   https://lists.jboss.org/mailman/listinfo/rules-users
> -- 
>   Edson Tirelli
>   Software Engineer - JBoss Rules Core Developer
>   Office: +55 11 3529-6000
>   Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat @ www.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 lists.jboss.org  Wed Aug 22 17:15:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 22 Aug 2007 17:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1046) JobExecutorServlet
 cannot use local JNDI name to access datasource
In-Reply-To: <10473705.1187802858662.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10127208.1187817318587.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1046?page=all ]

Ronald van Kuijk updated JBPM-1046:
-----------------------------------

                   Summary: JobExecutorServlet cannot use local JNDI name to access datasource  (was: JobExecutorServlet cannot use local JNDI name to access fatasource)
    Workaround Description: workaround exists by using the source and changing the datasource jndi name
             Fix Version/s: jBPM 3.3
                                (was:  jBPM jPDL 3.2.1)

> JobExecutorServlet cannot use local JNDI name to access datasource
> ------------------------------------------------------------------
>
>                 Key: JBPM-1046
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1046
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: Windows 2000
> IBM Websphere Application Server 6.1 (also reproduced on Websphere Test Environment 5.1)
> Oracle 9i database (with ojdbc14.jar release 9.2.0.8)
>            Reporter: Jacques Desmazi?res
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.3
>
>
> When configuraing jBPM / Hibernate with a datasource in an Enterprise application, using a local JNDI reference (java:comp/env/...) the web application works properly, accessing the database without any problem. 
> But if you declare the JobExecutorServlet in the web application's web.xml, each time the this servlet JobExecutorThread fires, it generates exceptions:
> [22/08/07 18:33:03:175 CEST] 0000005e SystemOut     O 18:33:03 DEBUG org.jbpm.job.executor.JobExecutorThread : acquiring jobs for execution...
> [22/08/07 18:33:03:315 CEST] 0000005f javaURLContex E   NMSV0310E: Une op?ration JNDI sur un nom "java:" ne peut pas aboutir car le contexte d'ex?cution du serveur ne peut pas associer l'unit? d'ex?cution de l'op?ration ? un composant d'application J2EE. Cette condition peut se produire lorsque le client JNDI utilisant le nom "java:" n'est pas ex?cut? sur l'unit? d'ex?cution d'une demande d'application du serveur. Assurez-vous qu'une application J2EE n'ex?cute pas d'op?rations JNDI sur des noms "java:" dans des blocs de code statiques ou dans des unit?s d'ex?cution cr??es par cette application J2EE. Un code de ce type ne s'ex?cute pas n?cessairement sur l'unit? d'ex?cution d'une demande d'application du serveur et n'est donc pas pris en charge par les op?rations JNDI sur les noms "java:". Trace de pile d'exceptions : 
> javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
> 	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:363)
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
> 	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
> 	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
> 	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
> 	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
> 	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
> 	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
> 	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
> 	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
> Caused by: javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
> 	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
> 	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
> 	... 17 more
>  
> [22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 FATAL org.hibernate.connection.DatasourceConnectionProvider : Could not find datasource: java:comp/env/jdbc/dsJBPM
> javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
> 	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:363)
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
> 	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
> 	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
> 	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
> 	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
> 	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
> 	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
> 	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
> 	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
> Caused by: 
> javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
> 	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
> 	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
> 	... 17 more
> [22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 ERROR org.jbpm.job.executor.JobExecutorThread : exception in job executor thread. waiting 10000 milliseconds
> org.hibernate.HibernateException: Could not find datasource
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:56)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
> 	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
> 	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
> 	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
> 	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
> 	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
> 	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
> 	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
> 	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
> Caused by: 
> javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
> 	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:363)
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
> 	... 13 more
> Caused by: 
> javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
> 	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
> 	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
> 	... 17 more
> The exception is raised even if there is no timer in the process definition.
> If I replace the local JNDI reference (java:comp/env/jdbc/datasource) with the global JNDI name (jdbc/dsOracle) the JobExecutorThread works fine (even if Websphere logs warning due to direct use of the global JNDI reference). The JobExecutorThread also works if I replace the datasource with the database access parameters (driver, url, ...).
> (sample ear is available to reproduce the bug if 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 lists.jboss.org  Wed Aug 22 18:22:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 22 Aug 2007 18:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
Message-ID: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
-----------------------------------------------------------------------------------------------------

                 Key: JBAS-4623
                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-4.2.2.GA
            Reporter: William DeCoste
         Assigned To: Remy Maucherat


MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().

Let me know if you see what I mean - I can fix it. 

I'm looking in Branch_4_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 lists.jboss.org  Wed Aug 22 18:24:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Wed, 22 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9298528.1187821458324.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer reassigned JBRULES-1109:
---------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Fernando Meyer
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 18:33:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 22 Aug 2007 18:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1031) Potential bug
 in cancelling delivery
In-Reply-To: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20566303.1187821998271.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBMESSAGING-1031:
-----------------------------------------

    Attachment: test.patch

to modify ejb3mdb to replicate this issue, apply this patch...

use:

patch -p0 < test.patch on the project root dir

> Potential bug in cancelling delivery
> ------------------------------------
>
>                 Key: JBMESSAGING-1031
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>         Attachments: test.patch
>
>
> Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 19:01:19 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 19:01:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-743) For polling
 callback handler, 
 org.jboss.remoting.Client.addListener() should create only one
 CallbackPoller per InvokerCallbackHandler
In-Reply-To: <28950543.1178341672458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5525766.1187823679030.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Unit test:  org.jboss.test.remoting.callback.pull.UniqueCallbackPollerTestCase.

> For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-743
>                 URL: http://jira.jboss.com/jira/browse/JBREM-743
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. 
> The semantics, according to Chapter 5 of the Remoting guide, should be
> If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect.
> So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 19:10:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 19:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15853214.1187824231591.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The address to which the secondary ServerSocket is bound is now the same as that to which the "primary" ServerSocket is bound. The address sent to the client to use in connecting to the secondary ServerSocket is taken from the server's InvokerLocator.  It follows that if the "clientConnectAddress" property is set, its value will be used for the secondary ServerSocket.  

Also, there are two new configurable parameters in the class org.jboss.remoting.transport.bisocket.Bisocket specific to the bisocket transport:

Code:

   public static final String SECONDARY_BIND_PORT = "secondaryBindPort";
   public static final String SECONDARY_CONNECT_PORT = "secondaryConnectPort";
	

SECONDARY_BIND_PORT determines which port the secondary ServerSocket binds to, and SECONDARY_CONNECT_PORT determines which port is sent to the client to use in connecting to the secondary ServerSocket. 

There are two advantages to the new configuration properties.  

1. Being able to specify the secondary connect address makes it possible to run a bisocket server behind a NAT router.

2. Being able to specify the secondary bind port makes it possible to run a bisocket server behind a firewall.

The changes have been implemented for the 2.2.2.GA release.  They need to be applied to the remoting_2_x branch.

Unit test:  org.jboss.test.remoting.callback.pull.UniqueCallbackPollerTestCase.

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 19:56:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 19:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26421592.1187826978213.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The fix is add a line to MicroSocketClientInvoker.handleDisconnect() so that it explicitly clears its own pool by calling clearPool(pool);



> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 20:21:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13381041.1187828478222.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The fix has been applied to the remoting_2_x branch and for release 2.2.2.GA.

Unit test:  org.jboss.test.remoting.transport.socket.connectionpools.ClearConnectionPoolsTestCase.

> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 20:26:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10670514.1187828778227.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal resolved JBREM-783.
-----------------------------

    Resolution: Won't Fix

This issue was introduced in the process of getting a JBossMessaging stress test to pass: org.jboss.test.messaging.jms.stress.SeveralClientsStressTest.  It turns out that other code and configuration changes were sufficient for that test to pass, so these changes have been backed out.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Wed Aug 22 20:28:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 20:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <12929149.1187828898297.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale updated JBRULES-1112:
-----------------------------------

    Security: Public  (was: JBoss Customer)

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Mark Proctor
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 20:30:33 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Wed, 22 Aug 2007 20:30:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <15927763.1187829033962.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer reassigned JBRULES-1112:
---------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 20:30:34 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Wed, 22 Aug 2007 20:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <7138848.1187829034117.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373430 ] 
            
Fernando Meyer commented on JBRULES-1112:
-----------------------------------------

There is no bundle for any jboss version in jetty home page http://sourceforge.net/project/showfiles.php?group_id=7322 it points to a empty project page in sourceforge. 
Otherwise I have brms working fine with jetty 6.1.1, Just adding three missing libraries jboss-faces.jar, jsf-api.jar and jsf-impl.jar. 

This guy is editing the JBRMS.jsp and adding unnecessary things as well there is no jboss-faces jar in classpath. probably thats the main reason for that error. But, I can't test because I didn't found the bundle for jboss at jetty page. 

Fernando

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 20:32:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14138954.1187829138241.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal resolved JBREM-793.
-----------------------------

    Resolution: Done

This synchronization was necessary in the context of changes made for JBREM-783 "Remove network i/o from synch blocks that establish and terminate LeasePingers", which introduced a race condition.  Since the changes for JBREM-783 was backed out, the current issue can be dropped.

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Wed Aug 22 20:37:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5705961.1187829438621.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal reopened JBREM-793:
-----------------------------

             

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Wed Aug 22 20:39:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13630427.1187829558219.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ron Sigal resolved JBREM-793.
-----------------------------

    Resolution: Won't Fix

Should have closed with "Won't Fix" resolution instead of "Done".

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Wed Aug 22 21:00:29 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 21:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-794)
 LeasePinger.addClient() should
 not create a new LeaseTimerTask if none currently exists
In-Reply-To: <18755133.1187587681051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5611848.1187830829794.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Change applied for release 2.2.2.GA and on branch remoting_2_x.

Unit test:  org.jboss.test.remoting.lease.UniquePingerTaskTestCase.

> LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists
> ---------------------------------------------------------------------------------------
>
>                 Key: JBREM-794
>                 URL: http://jira.jboss.com/jira/browse/JBREM-794
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> When org.jboss.remoting.LeasePinger.addClient() adds a new org.jboss.remoting.Client with a shorter ping period, it restarts the LeaseTimerTask.  However, org.jboss.remoting.MicroRemoteClientInvoker.establishLease() calls LeasePinger.addClient() before it calls LeasePinger.startPing().  LeasePinger incorrectly creates a LeaseTimerTask in addClient() and then creates a second one in startPing().
> LeasePinger.addClient() should be changed so that it starts a new LeaseTimerTask only if one already 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 lists.jboss.org  Wed Aug 22 21:17:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 21:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <5694797.1187831838455.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373435 ] 
            
Michael Neale commented on JBRULES-1112:
----------------------------------------

some of those files have since been removed - they are old and incorrect. If you go to the main url that the app is on, the index.jsp will redirect to the correct URL automatically. 

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 21:42:18 2007
From: jira-events at lists.jboss.org (Jose Pedro Pereira (JIRA))
Date: Wed, 22 Aug 2007 21:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-536) Add a
 display-name property
 per portal object that contains a i18n name for displaying object
Message-ID: <1984743.1187833338655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-536?page=comments#action_12373436 ] 
            
Jose Pedro Pereira commented on JBPORTAL-536:
---------------------------------------------

We extended the object_node object on version 2.4 to at least support a display label on each object node. We have also added other properties, such as "open in external window" and "external url", etc... How can we contribute this changes? 

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


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 21:44:23 2007
From: jira-events at lists.jboss.org (Jose Pedro Pereira (JIRA))
Date: Wed, 22 Aug 2007 21:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-771) introduce page
	inheritance
Message-ID: <13814553.1187833463393.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-771?page=comments#action_12373437 ] 
            
Jose Pedro Pereira commented on JBPORTAL-771:
---------------------------------------------

We have implemented not a solution of page inheritance, but a solution of "page copy", with possible recursion (meaning copy all sub-pages) and portlet windows. What is the best way to contribute this changes?

> introduce page inheritance
> --------------------------
>
>                 Key: JBPORTAL-771
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-771
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Martin Holzner
>
> We have at least one concrete example already that shows the need of such a feature, but I'm sure there are many more. 
> Right now all pages that want to expose the tabed navigation in the top need to add the NavigationPortletWindow in the navigation region. It would make it much easier to create 'templated' pages that contain certain behaviour like the navigation , if we'd allow each page to inherit from another. 
> This would enable the admin to create some useful template pages that all other pages can inherit from, and hence get the same bahaviour. No need to place the same portlet windows on every page anymore.
> We could implement this as
>  * 'real' inheritence that is kept in the PortalObject tree and evealuated in each page request (or each modification to a portal object), or
>  * templating solution, that makes a hard copy into the new page without any future tie back to the 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 lists.jboss.org  Wed Aug 22 21:57:19 2007
From: jira-events at lists.jboss.org (Jose Pedro Pereira (JIRA))
Date: Wed, 22 Aug 2007 21:57:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1647) Integrate Portal
 Login with
 CAS (edu.yale Central Authentication Service) and automate fetching of user
 groups/roles and other information from ldap directory services
Message-ID: <30995864.1187834239145.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate Portal Login with CAS (edu.yale Central Authentication Service) and automate fetching of user groups/roles and other information from ldap directory services
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1647
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1647
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Security
            Reporter: Jose Pedro Pereira
         Assigned To: Julien Viet


We have allready developed this integration... It is not a single and pretty solution, as it dependes on jboss configuration, extension of the embeded tomcat login modules, special login contexts and additional rules classes to gather all the information needed, but we do have such setups... What is the best way to contribute this code and document the required changes to a standard install? Maybe this could be made simpler and more generic... 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 00:24:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 23 Aug 2007 00:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-796) Verify Remoting
 2.2.2 is compatible with earlier versions
Message-ID: <17644775.1187843058201.JavaMail.jira@cloud.prod.atl2.jboss.com>

Verify Remoting 2.2.2 is compatible with earlier versions
---------------------------------------------------------

                 Key: JBREM-796
                 URL: http://jira.jboss.com/jira/browse/JBREM-796
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.2.GA
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.2.GA


Need to add version 2.2.0.SP4 jboss-remoting.jar to src/etc/lib and run tests.versioning.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 lists.jboss.org  Thu Aug 23 00:38:18 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Thu, 23 Aug 2007 00:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-536) Add a
 display-name property
 per portal object that contains a i18n name for displaying object
Message-ID: <11056603.1187843898321.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-536?page=comments#action_12373439 ] 
            
Julien Viet commented on JBPORTAL-536:
--------------------------------------

you need to
provide a patch
create a jira issue targetting the version that patch fixes in
sign up the contributor agreement
attach the patch to the jira issue


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


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:09:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 23 Aug 2007 01:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-796) Verify Remoting
 2.2.2 is compatible with earlier versions
In-Reply-To: <17644775.1187843058201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1284591.1187845758238.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Running tests.versioning.all shows that Remoting from branch 2_2_0_GA tagged remoting_2_2_2_Beta (i.e., Remoting 2.2.2.Beta) is compatible with versions:

   2_2_0_SP4
   2_0_0_GA
   1_4_6_GA
   1_4_4_GA
   1_4_3_GA

> Verify Remoting 2.2.2 is compatible with earlier versions
> ---------------------------------------------------------
>
>                 Key: JBREM-796
>                 URL: http://jira.jboss.com/jira/browse/JBREM-796
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> Need to add version 2.2.0.SP4 jboss-remoting.jar to src/etc/lib and run tests.versioning.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 lists.jboss.org  Thu Aug 23 01:21:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1036) TimeOut method
 callback has no security context
Message-ID: <8577170.1187846478268.JavaMail.jira@cloud.prod.atl2.jboss.com>

TimeOut method callback has no security context
-----------------------------------------------

                 Key: EJBTHREE-1036
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1036
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Spec 18.2.2:
"Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity." 


Basically the ejbTimeout callback should have zero security checks (bypass auth, authorization, runas).  This is in line with ejb2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:21:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1036) TimeOut method
 callback should bypass security as it has no security context
In-Reply-To: <8577170.1187846478268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2663576.1187846478380.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana updated EJBTHREE-1036:
------------------------------------

    Summary: TimeOut method callback should bypass security as it has no security context  (was: TimeOut method callback has no security context)

> TimeOut method callback should bypass security as it has no security context
> ----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1036
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1036
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity." 
> Basically the ejbTimeout callback should have zero security checks (bypass auth, authorization, runas).  This is in line with ejb2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:31:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1027) Timeout method
 gets called with an unspecified caller identity
In-Reply-To: <6643972.1186567051460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11439646.1187847078252.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1027?page=comments#action_12373442 ] 
            
Anil Saldhana commented on EJBTHREE-1027:
-----------------------------------------

Please look at EJBTHREE-1036 which leads to a security bypass due to ejbTimeOut callback having no security context as per spec.  So any call to getCallerPrincipal should return the unauthenticatedIdentity of the security domain that drives the ejb.

EJBTHREE-1036 is done for JBAS5 trunk.


> Timeout method gets called with an unspecified caller identity
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1027
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1027
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: AS 4.2.1.GA
>            Reporter: Carlo de Wolf
>
> Having a secured bean with a timeout method with @PermitAll, but without an unauthenticatedIdentity will lead to a 'random' identity being used to call the method or no identity at all. The last one leads to EJBAccessExceptions.
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity."
> We must disallow all calls to a timeout method if unauthenticatedIdentity is not 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 lists.jboss.org  Thu Aug 23 01:31:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1036) TimeOut method
 callback should bypass security as it has no security context
In-Reply-To: <8577170.1187846478268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31008277.1187847078385.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1036?page=comments#action_12373443 ] 
            
Anil Saldhana commented on EJBTHREE-1036:
-----------------------------------------

This is complete in JBAS5 Trunk version of EJB3.  Please set the appropriate version and close this issue.

> TimeOut method callback should bypass security as it has no security context
> ----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1036
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1036
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity." 
> Basically the ejbTimeout callback should have zero security checks (bypass auth, authorization, runas).  This is in line with ejb2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:35:29 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 01:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1113) renaming a
 package messes up the assets in it
Message-ID: <18471627.1187847329362.JavaMail.jira@cloud.prod.atl2.jboss.com>

renaming a package messes up the assets in it 
----------------------------------------------

                 Key: JBRULES-1113
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1113
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Michael Neale
            Priority: Critical
             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 01:42:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 01:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1037) fix RunAs
 principal propagation
Message-ID: <27581534.1187847738271.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix RunAs principal propagation
-------------------------------

                 Key: EJBTHREE-1037
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1037
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA
            Reporter: William DeCoste
         Assigned To: William DeCoste


We decided it would the principal associated with the run-as identity.
In this case its anonymous unless overridden in the run-as config. This
is what the cts14 tests required. We used to return the original caller
principal, but with the need to assign multiple roles to the run-as
principal for the cts14 tests, we switched this to a separate run-as
principal. The ejb3-spec is a little more clear about there being a
run-as principal:

17.1:
The security principal under which a method invocation is performed is
typically that of the component's caller. By specifying a run-as
identity, however, it is possible to specify that a different principal
be substituted for the execution of the methods of the bean's business
interface, home interface, component interface, and/or web service
endpoint and any methods of other enterprise beans that the bean may
call.
This determines whether the caller principal is propagated from the
caller to the callee?that is, whether the called enterprise bean will
see the same returned value of the EJBContext.getCallerPrincipal
as the calling enterprise bean?or whether a security principal that has
been assigned to the specified security role will be used for the
execution of the bean's methods and will be visible as the
caller principal in the bean's callee.

17.3.4 Specification of Security Identities in the Deployment Descriptor
...
Because the Bean Provider and Application Assembler do not, in general,
know the security environment of the operational environment, the run-as
identity is designated by a logical role-name, which
corresponds to one of the security roles defined by the Bean Provider or
Application Assembler in the metadata annotations or deployment descriptor.
The Deployer then assigns a security principal defined in the
operational environment to be used as the principal for the run-as
identity. The security principal assigned by the Deployer should be a
principal that has been assigned to the security role specified by RunAs
annotation or by the role-name element of the run-as deployment
descriptor element.
The Bean Provider and/or Application Assembler is responsible for the
following in the specification of run-as identities:
? Use the RunAs metadata annotation or role-name element of the run-as
deployment descriptor element to define the name of the security role.
? Optionally, use the description element to provide a description of
the principal that is expected to be bound to the run-as identity in
terms of its security role.

17.4.3 Principal Delegation
The Deployer is responsible for configuring the principal delegation for
inter-component calls. The Deployer must follow any instructions
supplied by the Bean Provider and/or Application Assembler
(for example, provided in the RunAs metadata annotations, the run-as
elements of the deployment descriptor, in the description elements of
the annotations or deployment descriptor, or in a deployment manual).
If the security identity is defaulted, or it is explicitly specified
that the caller identity be used (e.g., use-caller-identity deployment
descriptor element is specified), the caller principal is propagated
from one component to another (i.e., the caller principal of the first
enterprise bean in a call-chain is passed to the enterprise beans down
the chain).
If the Bean Provider or Application Assembler specifies that a run-as
identity be used on behalf of a particular enterprise bean, the Deployer
must configure the enterprise beans such that the run-as principal is
used as the caller principal on any calls that the enterprise bean makes
to other beans, and that the run-as principal is propagated along the
call-chain of those other beans (in the absence of the specification of
any further run-as elements).

Anil Saldhana wrote:
> > Scott,
> >   Bill Decoste and I have a simple difference in understanding of
> > RunAsIdentity in relation to getCallerPrincipal
> > 
> > BeanA ->  BeanB
> > 
> > BeanA defines a RunAs annotation with a role.  No principal is attached
> > to this annotation (so we will take anonymous as the principal).
> > 
> > If a Principal  "anil"  invoked BeanA.  Then a method in BeanA called a
> > method in BeanB.
> > 
> > If BeanB does a getCallerPrincipal,  does it return "anonymous" that is
> > attached to run-as or it will return "Somebody"?   I am saying
> > "anonymous" and BillD says it is "anil".
> > 
> > My understanding is that RunAs does a security context switch and a
> > security-identity in ejb-jar.xml with <use-caller-identity> would
> > propogate.
> > 
> > Can you clarify, please?
> > 
> > Regards,
> > Anil
> > 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Thu Aug 23 01:55:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 01:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1113) renaming a package
 messes up the assets in it
In-Reply-To: <18471627.1187847329362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25530711.1187848518207.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-1113.
----------------------------------

    Resolution: Done

> renaming a package messes up the assets in it 
> ----------------------------------------------
>
>                 Key: JBRULES-1113
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1113
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>            Priority: Critical
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 02:01:30 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 02:01:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1113) renaming a
 package messes up the assets in it
In-Reply-To: <18471627.1187847329362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27797085.1187848890365.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1113?page=comments#action_12373444 ] 
            
Michael Neale commented on JBRULES-1113:
----------------------------------------

was due to not renaming the package name in the assets - this is necessary as each asset keeps a copy of the package name (needed for versioning -bloody versioning, as always).

> renaming a package messes up the assets in it 
> ----------------------------------------------
>
>                 Key: JBRULES-1113
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1113
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>            Priority: Critical
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 03:38:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 03:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1020) BRMS Custom Rule
 Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10669828.1187854698320.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Michael Neale closed JBRULES-1020.
----------------------------------

    Resolution: Done

done for 4.0.1 allowing custom selectors (either a drl or a class implementation can be configured by a sys admin).

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 23 03:40:45 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 23 Aug 2007 03:40:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7413998.1187854845633.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4567?page=comments#action_12373455 ] 
            
Thomas Diesler commented on JBAS-4567:
--------------------------------------

The target for Beta3 is 2.0.x

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 04:52:18 2007
From: jira-events at lists.jboss.org (Alexandre Russel (JIRA))
Date: Thu, 23 Aug 2007 04:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1011) Component to
 calculate the memory footprint of elements in the cache
In-Reply-To: <17611450.1174489728864.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7684305.1187859138239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1011?page=comments#action_12373459 ] 
            
Alexandre Russel commented on JBCACHE-1011:
-------------------------------------------

do you have any info on: "Java5 java offers support for determining the size of objects"

AFAIK, java 5 only allows to know memory usage and send notification when a threshold is exceeded
on pools that supports it.
Calculating memory usage before and after object allocation would give a wrong size of objects and
 would be unusable in J2EE. Especially because if I put a List in the cache and add object to the list I 
would need to know the total size of list + objects, so I need to trace each object allocation.

I think this issue should closed as long as knowing the size of objects is not accurate.
alex



> Component to calculate the memory footprint of elements in the cache
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-1011
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1011
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Mircea Markus
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>
> As with Java5 java offers support for determining the size of objects. An memory based eviction policy can be written for this java version only. The basic idea is to let the user to specify the amount of memory he wants to 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 lists.jboss.org  Thu Aug 23 06:19:19 2007
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 23 Aug 2007 06:19:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27361487.1187864359007.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-89?page=comments#action_12373464 ] 
            
Jean-Frederic Clere commented on JBWEB-89:
------------------------------------------

To reproduce it just configure a cluster with jvmRoute of different length. Send a request to the one has the small jvmRoute and failover to the one with long jvmRoute for the next request.

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Jean-Frederic Clere
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:05:22 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 23 Aug 2007 07:05:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-200) Make sure the batch
 and sh files work
Message-ID: <15610964.1187867122589.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-200?page=all ]

Stale Pedersen resolved JBAOP-200.
----------------------------------

    Resolution: Done

confirmed that the fixes works on both linux and windows.

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:05:22 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 23 Aug 2007 07:05:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-200) Make sure the batch
 and sh files work
Message-ID: <19983135.1187867122900.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-200?page=all ]

Stale Pedersen closed JBAOP-200.
--------------------------------


> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:36:18 2007
From: jira-events at lists.jboss.org (Dean Jones (JIRA))
Date: Thu, 23 Aug 2007 07:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1114) Rule compilation
 not thread-safe
Message-ID: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule compilation not thread-safe
--------------------------------

                 Key: JBRULES-1114
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Dean Jones
         Assigned To: Mark Proctor


Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.

See http://thread.gmane.org/gmane.comp.java.drools.user/7834


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:42:18 2007
From: jira-events at lists.jboss.org (Dean Jones (JIRA))
Date: Thu, 23 Aug 2007 07:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1114) Rule compilation
 not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24664839.1187869338282.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dean Jones updated JBRULES-1114:
--------------------------------

    Attachment: PackageBuilderThreadSafetyTest.java

Adding a test case. Note that this is not guaranteed to fail, but is pretty likely to fail.


> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Mark Proctor
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 08:49:34 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 08:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
Message-ID: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>

Undeploying a portlet in an exploded form causes a NullPointerException
-----------------------------------------------------------------------

                 Key: JBPORTAL-1648
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final
         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
            Reporter: Martin Putz


The process to reproduce the issue :
1- start jboss as
2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
4- remove the portlet directory (helloworldportalpage.war from deploy/)
5- go to the 'MyPage' page, you should see the NullPointerException:

java.lang.NullPointerException
at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
...


Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 08:49:34 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 08:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11611212.1187873374627.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Martin Putz updated JBPORTAL-1648:
----------------------------------

    Help Desk Ticket Reference: https://na1.salesforce.com/50030000003QWf4

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 08:51:18 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 08:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12028900.1187873478274.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Martin Putz updated JBPORTAL-1648:
----------------------------------

    Help Desk Ticket Reference:   (was: https://na1.salesforce.com/50030000003QWf4)

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:30:18 2007
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 23 Aug 2007 09:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28242080.1187875818913.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-89?page=all ]

Jean-Frederic Clere resolved JBWEB-89.
--------------------------------------

    Resolution: Done

I have fixed the branches 4.2.x and 4.0.x trunk is ok the logic is different there.

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Jean-Frederic Clere
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:32:18 2007
From: jira-events at lists.jboss.org (Anthony Dawson (JIRA))
Date: Thu, 23 Aug 2007 09:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1115) Modifications to
 list objects
 contained within a bean and carried out during the execution of a rule are
 not reflected in the original list i.e. the changes are lost  between the
 instance available within the rule  and that of the original bean
Message-ID: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1115
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: HP-UX  java version "1.5.0.05"

            Reporter: Anthony Dawson
         Assigned To: Mark Proctor


Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean

During the execution of the rules when I modify a list my changes are not reflected in my bean. 
Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.

Details of this problem are described in the forum messages.

http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:40:18 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 23 Aug 2007 09:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4624) Parse Role Name from
	Role DN
Message-ID: <10860214.1187876418658.JavaMail.jira@cloud.prod.atl2.jboss.com>

Parse Role Name from Role DN
----------------------------

                 Key: JBAS-4624
                 URL: http://jira.jboss.com/jira/browse/JBAS-4624
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Mike Millson
         Assigned To: Anil Saldhana


Improve the performance of the LdapExtLoginModule by adding a parseRoleNameFromDN option or check the returned DN to see if it already includes the roleNameAttributeID, and if it does, parse the roleNameAttributeID from the DN rather than querying LDAP for the roleNameAttributeID.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:42:19 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 23 Aug 2007 09:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4625) Connection leak if
 failure to setup connection in jms inbound resource adapter
Message-ID: <4162579.1187876539379.JavaMail.jira@cloud.prod.atl2.jboss.com>

Connection leak if failure to setup connection in jms inbound resource adapter
------------------------------------------------------------------------------

                 Key: JBAS-4625
                 URL: http://jira.jboss.com/jira/browse/JBAS-4625
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


The jms inbound resource adapter is leaking connections if there is an error
setting up the connection.

In pseudo code in setup[Queue|Topic]Connection
{
      ...
+      try
+      {
         if (clientID != null)
            result.setClientID(clientID);
         result.setExceptionListener(this);
         log.debug("Using topic connection " + result);
         return result;
+     }
+     catch (Throwable t)
+     {
+        result.close();
+        throw 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 lists.jboss.org  Thu Aug 23 09:44:34 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 23 Aug 2007 09:44:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4624) Parse Role Name from
	Role DN
In-Reply-To: <10860214.1187876418658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3376222.1187876674920.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mike Millson closed JBAS-4624.
------------------------------

    Resolution: Duplicate Issue

This should have been created as an ASPATCH.

> Parse Role Name from Role DN
> ----------------------------
>
>                 Key: JBAS-4624
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4624
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>
> Improve the performance of the LdapExtLoginModule by adding a parseRoleNameFromDN option or check the returned DN to see if it already includes the roleNameAttributeID, and if it does, parse the roleNameAttributeID from the DN rather than querying LDAP for the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:48:18 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 09:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19502509.1187876898321.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Martin Putz updated JBPORTAL-1648:
----------------------------------

    Attachment: patch.txt

attached a patch for org.jboss.portal.server.deployment.jboss.Deployment

On exploded deployments, the URL to the /WEB-INF folder of a web app was missing the trailing slash. With this corrupted path information, the undeployment procedure failed to find the corresponding entry in the MainDeployer's map of deployed elements. As a result, the contents of the /WEB-INF folder were not undeployed completely.

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>         Attachments: patch.txt
>
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:54:18 2007
From: jira-events at lists.jboss.org (Dean Jones (JIRA))
Date: Thu, 23 Aug 2007 09:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
Message-ID: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>

"not" doesn't work for StatelessSessions
----------------------------------------

                 Key: JBRULES-1116
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Dean Jones
         Assigned To: Mark Proctor
            Priority: Blocker


When using a StatelessSession, the "not" quantifier doesn't work. Test case below.

package org.drools.examples

rule "Hello World"
       when
           Integer()
       then
           System.out.println("Hello world");
end

rule "Goodbye World"
       when
           not Integer()
       then
           System.out.println("Goodbye cruel world");
end

public class TestReadRuleFile {

 public static void main(String[] args) throws Exception {
  PackageBuilder builder = new PackageBuilder();
  InputStreamReader is = new InputStreamReader(
   TestReadRuleFile.class.getResourceAsStream("test.drl"));
  builder.addPackageFromDrl(is);
  Package pkg = builder.getPackage();
  RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
  jbossRulebase.addPackage(pkg);
  StatelessSession session = jbossRulebase.newStatelessSession();
  session.execute(new Float(1));
 }

}

The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:59:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 23 Aug 2007 09:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4625) Connection leak if
 failure to setup connection in jms inbound resource adapter
In-Reply-To: <4162579.1187876539379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5761504.1187877558291.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Adrian Brock closed JBAS-4625.
------------------------------

    Resolution: Done

> Connection leak if failure to setup connection in jms inbound resource adapter
> ------------------------------------------------------------------------------
>
>                 Key: JBAS-4625
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4625
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> The jms inbound resource adapter is leaking connections if there is an error
> setting up the connection.
> In pseudo code in setup[Queue|Topic]Connection
> {
>       ...
> +      try
> +      {
>          if (clientID != null)
>             result.setClientID(clientID);
>          result.setExceptionListener(this);
>          log.debug("Using topic connection " + result);
>          return result;
> +     }
> +     catch (Throwable t)
> +     {
> +        result.close();
> +        throw 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 lists.jboss.org  Thu Aug 23 10:18:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1168) Sometimes aquired
 locks are not released
Message-ID: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>

Sometimes aquired locks are not released
----------------------------------------

                 Key: JBCACHE-1168
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
    Affects Versions: 1.4.1.SP4
         Environment: Windows XP, jrockit90_150_06 
Solaris 10
            Reporter: Jacek Halat
         Assigned To: Jason T. Greene
         Attachments: TransactionStormTest.java

Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
Main loop:
		while (true) {
			for (int x = 0; x < 2; x++) {
				WorkThread t = new WorkThread(x == 1);
				threads.add(t);
				t.start();
			}
			for (WorkThread separateThread : threads) {
				separateThread.join();
				if (separateThread.getException() != null) {
					//separateThread.getException().getMessage();
				}
			}
			int locksNum = getNumberOfLocksHeld();
//			System.out.println("Locks="+locksNum);
			// checkpoint
			if (cache.getNumberOfLocksHeld()>0){
				System.out.println("ERROR, locks="+locksNum);
				doDomethingOnCache(1);
			}
			assertEquals(0, locksNum);
		}


Exception - after //checkpoint line numberOfLocks is grater than 0!

JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 10:18:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1168) Sometimes aquired
 locks are not released
In-Reply-To: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10277241.1187878698837.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1168?page=all ]

Jacek Halat updated JBCACHE-1168:
---------------------------------

    Attachment: TransactionStormTest.java

Test to this issue.

> Sometimes aquired locks are not released
> ----------------------------------------
>
>                 Key: JBCACHE-1168
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, jrockit90_150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: TransactionStormTest.java
>
>
> Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
> Main loop:
> 		while (true) {
> 			for (int x = 0; x < 2; x++) {
> 				WorkThread t = new WorkThread(x == 1);
> 				threads.add(t);
> 				t.start();
> 			}
> 			for (WorkThread separateThread : threads) {
> 				separateThread.join();
> 				if (separateThread.getException() != null) {
> 					//separateThread.getException().getMessage();
> 				}
> 			}
> 			int locksNum = getNumberOfLocksHeld();
> //			System.out.println("Locks="+locksNum);
> 			// checkpoint
> 			if (cache.getNumberOfLocksHeld()>0){
> 				System.out.println("ERROR, locks="+locksNum);
> 				doDomethingOnCache(1);
> 			}
> 			assertEquals(0, locksNum);
> 		}
> Exception - after //checkpoint line numberOfLocks is grater than 0!
> JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 10:20:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1168) Sometimes aquired
 locks are not released
In-Reply-To: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19652375.1187878818389.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1168?page=all ]

Jacek Halat updated JBCACHE-1168:
---------------------------------

    Attachment: output.txt

Example console output with error

> Sometimes aquired locks are not released
> ----------------------------------------
>
>                 Key: JBCACHE-1168
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, jrockit90_150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: output.txt, TransactionStormTest.java
>
>
> Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
> Main loop:
> 		while (true) {
> 			for (int x = 0; x < 2; x++) {
> 				WorkThread t = new WorkThread(x == 1);
> 				threads.add(t);
> 				t.start();
> 			}
> 			for (WorkThread separateThread : threads) {
> 				separateThread.join();
> 				if (separateThread.getException() != null) {
> 					//separateThread.getException().getMessage();
> 				}
> 			}
> 			int locksNum = getNumberOfLocksHeld();
> //			System.out.println("Locks="+locksNum);
> 			// checkpoint
> 			if (cache.getNumberOfLocksHeld()>0){
> 				System.out.println("ERROR, locks="+locksNum);
> 				doDomethingOnCache(1);
> 			}
> 			assertEquals(0, locksNum);
> 		}
> Exception - after //checkpoint line numberOfLocks is grater than 0!
> JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 10:57:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1168) Sometimes aquired
 locks are not released
In-Reply-To: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22612498.1187881039013.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1168?page=all ]

Jacek Halat updated JBCACHE-1168:
---------------------------------

    Attachment: jbosscache.log

Logs from TreeCache (in DEBUG mode).
Important fragment:
After every rollback logs contains:
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/d, marked for removal.
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/c, marked for removal.
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/b, marked for removal.
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/a, marked for removal. 


but in one case:
2007-08-23 16:46:33,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:33,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/d, marked for removal.
2007-08-23 16:46:33,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:33,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/c, marked for removal.
2007-08-23 16:46:33,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:33,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/b, marked for removal. 

Where is entry for /a/b/c/a node? 
>From now /a/b/c/a is locked forever.

> Sometimes aquired locks are not released
> ----------------------------------------
>
>                 Key: JBCACHE-1168
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, jrockit90_150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: jbosscache.log, output.txt, TransactionStormTest.java
>
>
> Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
> Main loop:
> 		while (true) {
> 			for (int x = 0; x < 2; x++) {
> 				WorkThread t = new WorkThread(x == 1);
> 				threads.add(t);
> 				t.start();
> 			}
> 			for (WorkThread separateThread : threads) {
> 				separateThread.join();
> 				if (separateThread.getException() != null) {
> 					//separateThread.getException().getMessage();
> 				}
> 			}
> 			int locksNum = getNumberOfLocksHeld();
> //			System.out.println("Locks="+locksNum);
> 			// checkpoint
> 			if (cache.getNumberOfLocksHeld()>0){
> 				System.out.println("ERROR, locks="+locksNum);
> 				doDomethingOnCache(1);
> 			}
> 			assertEquals(0, locksNum);
> 		}
> Exception - after //checkpoint line numberOfLocks is grater than 0!
> JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 11:27:18 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Aug 2007 11:27:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1052) When running
 stress tests wrong log4j.xml is picked up
Message-ID: <10580807.1187882838240.JavaMail.jira@cloud.prod.atl2.jboss.com>

When running stress tests wrong log4j.xml is picked up
------------------------------------------------------

                 Key: JBMESSAGING-1052
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1052
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


When running stress tests, the log4j.xml from tests/etc, but the log4j.xml from tests/etc/stress isn't being used.

This means stress tests are being run on trace logging, which is incorrect (makes them take ages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:41:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18695620.1187883678474.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1116:
-----------------------------------

      Component/s: Drl Parser/Builder
                   Reteoo
    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:43:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1115) Modifications to
 list objects
 contained within a bean and carried out during the execution of a rule are
 not reflected in the original list i.e. the changes are lost  between the
 instance available within the rule  and that of the original bean
In-Reply-To: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7245682.1187883798332.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1115:
-----------------------------------

      Component/s: Reteoo
                       (was: Drl Parser/Builder)
    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1115
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: HP-UX  java version "1.5.0.05"
>            Reporter: Anthony Dawson
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> During the execution of the rules when I modify a list my changes are not reflected in my bean. 
> Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.
> Details of this problem are described in the forum messages.
> http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:43:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1114) Rule compilation
 not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33326527.1187883798493.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1114:
-----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:45:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22238769.1187883918464.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1091:
-----------------------------------

    Component/s: Reteoo

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Thu Aug 23 11:45:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24361259.1187883918685.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1111:
-----------------------------------

      Component/s: Reteoo
    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:45:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1110) Rules with 'From'
 condition with another not using From causes problem
In-Reply-To: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15561331.1187883918882.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1110:
-----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Rules with 'From' condition with another not using From causes problem
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1110
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Decision tables
>    Affects Versions:  4.0.0.GA
>         Environment: Any
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Test case:
> Write a Rule that uses a From clause and on another object does not use a from clause:
> example:
> #From row number: 28
> rule "Rules_28"
> 	
> 	when
> 		cntct: Contact(initialized==true)
> 		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
> 		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
> 	then
>                              System.out.println("Fired 28");
> end
> If All 3 are true:
>  1. Delete Condition 2 --> Rule fires
>  2. Delete COnditon 3 (But keep 2) --> Rule fires
>  3. Keep 2 & 3 (with 1) --> Rule does not fire
> Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.
> Please see if it is 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 lists.jboss.org  Thu Aug 23 11:47:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1105) web.xml does not
 conform web-app_2_3.dtd
In-Reply-To: <3916092.1187585177133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19161929.1187884038599.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1105:
-----------------------------------

    Fix Version/s: 4.0.1
                       (was:  4.0.0.GA)
         Assignee: Fernando Meyer  (was: Mark Proctor)

> web.xml does not conform web-app_2_3.dtd
> ----------------------------------------
>
>                 Key: JBRULES-1105
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1105
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Glassfish
>            Reporter: Michael Max
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> web.xml does not comply with a http://java.sun.com/dtd/web-app_2_3.dtd specification. Because of that drools-jbrms.war cannot be deployed to the servers with a strict validation as Glassfish, just to JBoss AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:47:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1104) Inserted Objects
 are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7526969.1187884038750.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1104:
-----------------------------------

    Assignee: Mark Proctor  (was: Edson Tirelli)

> Inserted Objects are lost if no matching ObjectTypeNodes
> --------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:49:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1095) Deserializing
 Package Objects Consumes Large Amount of Memory
In-Reply-To: <17599698.1187293445172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24436120.1187884158436.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1095:
-----------------------------------

    Fix Version/s: FUTURE

> Deserializing Package Objects Consumes Large Amount of Memory
> -------------------------------------------------------------
>
>                 Key: JBRULES-1095
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1095
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>         Attachments: testdrools.zip
>
>
> Deserializing the Package objects from storage to memory consumes large amount of memory.  My tests showed that for a serialized size of 1MB, 18MB of memory would be consumed during deserialization, mostly from the method org.drools.rule.Package.readExternal.  A test program with resulting profile data would be uploaded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:49:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1048) Context assist is
 not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3882892.1187884158641.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1048:
-----------------------------------

    Component/s: Eclipse IDE

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Thu Aug 23 11:51:26 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:51:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29333839.1187884286720.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-992:
----------------------------------

    Fix Version/s: 4.0.1

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Thu Aug 23 11:53:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:53:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1063) Failing location
 determination tests
In-Reply-To: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22114808.1187884399044.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1063:
-----------------------------------

      Component/s: Drl Parser/Builder
    Fix Version/s: 4.0.1
                       (was: FUTURE)
         Assignee: Edson Tirelli  (was: Mark Proctor)

Please, in such cases, let the tests break the build and point them to me.

> Failing location determination tests
> ------------------------------------
>
>                 Key: JBRULES-1063
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  
> Their name is prefixed with FAILING
> I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
> The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:55:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1013) Two functions
 with Janino compiler end up with out of memory error
In-Reply-To: <13997820.1184691167170.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9923707.1187884518693.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1013:
-----------------------------------

          Component/s: Drl Parser/Builder
        Fix Version/s: FUTURE
                           (was: 4.0.1)
    Affects Version/s:  4.0.0.GA

> Two functions with Janino compiler end up with out of memory error
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1013
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1013
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Ubuntu Feisty, JDK 1.4 or 1.5, Drools Snapshot
>            Reporter: Pierre Paysant-Le Roux
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> Compiling a simple rules file containing two functions with janino causes an out of memory error.
> Rules file example :
> package test
> function boolean func1() {
> 	return true;
> }
> function boolean func2() {
> 	return true;
> }
> rule "test"
> when
> 	Object()
> then
> 	System.out.println("fired");
> end
> and the code that generate the error :
> package test;
> import java.io.IOException;
> import java.io.InputStreamReader;
> import java.util.Properties;
> import org.drools.compiler.DroolsParserException;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.PackageBuilderConfiguration;
> public class Test {
>     public static void main (String[] args) {
>         Properties properties = new Properties();
>         properties.setProperty("drools.dialect.java.compiler", 
>                                "JANINO");
>         PackageBuilderConfiguration pkgBuilderCfg = new PackageBuilderConfiguration(properties);
>         PackageBuilder builder = new PackageBuilder(pkgBuilderCfg);
>         try {
>             builder.addPackageFromDrl(getSource());
>         } catch (DroolsParserException e) {
>             e.printStackTrace();
>         } catch (IOException e) {
>             e.printStackTrace();
>         }
>     }
>     
>     private static InputStreamReader getSource() {
>         return new InputStreamReader(Test.class.getResourceAsStream( "Sample.drl" ));
>     }
> }
> After profiling, I identified that the problematic line is the 146 one in class JaninoJavaCompiler. It causes the loadIClass method to loop with a cycle that I don't understand. Placing a breakpoint on the line 91 of JaninoJavaCompiler class permit to observe the loop iterations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 12:05:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 12:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31157743.1187885118321.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-1111.
------------------------------------

    Resolution: Won't Fix

That happens because the engine needs to create shadow facts for objects asserted as facts and shadow facts are implemented as lazy proxies. If the class or the methods are final, the engine can't override them. 

So, we strongly discourage you to use final classes or methods as facts, specially if those methods are property accessors.

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 12:19:33 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Aug 2007 12:19:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-404) Create project
 site for jboss-deploy plugin.
In-Reply-To: <27716106.1187728638760.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7798958.1187885973864.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-404?page=all ]

Paul Gier reassigned JBBUILD-404:
---------------------------------

    Assignee: Paul Gier

> Create project site for jboss-deploy plugin.
> --------------------------------------------
>
>                 Key: JBBUILD-404
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-404
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: maven-jboss-deploy-plugin
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> There should be a project site that contains documentation for the plugin on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 12:32:18 2007
From: jira-events at lists.jboss.org (Felipe Piccolini (JIRA))
Date: Thu, 23 Aug 2007 12:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1117) DSL support for
 multiple mvel comparasions (like || ==) in several lines.
Message-ID: <29756989.1187886738288.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL support for multiple mvel comparasions (like || ==) in several lines.
-------------------------------------------------------------------------

                 Key: JBRULES-1117
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1117
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder, Eclipse IDE
    Affects Versions:  4.0.0.GA
         Environment: DSL editor and eclipse IDE.
            Reporter: Felipe Piccolini
         Assigned To: Mark Proctor
             Fix For: FUTURE


It whould be nice if DSL supports multiple lines for multiple comparison (mvel expression) against the same attribute.
Like this:
   DLS: 
       A Person
          - having age equals to 10
          - or equals to 15
          - or greather than 20

  DRL:
     p: Person( age == 10
                || == 15
                || > 20)

Right now, the " - <expression>"  put a 'comma' at the end of the line making this:
     p: Person( age == 10, || == 15, || > 20)

What throws errors...

  Is it possible to do that? I love the || == <value> thing in each line...

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 lists.jboss.org  Thu Aug 23 12:49:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 12:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
In-Reply-To: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13400960.1187887758836.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry reassigned JBAS-4623:
--------------------------------------

    Assignee: Brian Stansberry  (was: Remy Maucherat)

> org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4623
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: William DeCoste
>         Assigned To: Brian Stansberry
>
> MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().
> Let me know if you see what I mean - I can fix it. 
> I'm looking in Branch_4_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 lists.jboss.org  Thu Aug 23 12:58:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 12:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
In-Reply-To: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17064610.1187888298335.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

This class is not meant to be used inside JBoss AS; it's for use in standalone Tomcat.  It's also largely untested in that usage since I wrote it as a community contribution 2 1/2 years ago (i.e. before I joined JBoss/Red Hat).

A hacky fix to this hacky usage would be to only call MBeanServerLocator.setJBoss(getMBeanServer()) if MBeanServerLocator.locateJBoss() returns null. A better fix would be to figure out how to ensure no classes in the package need to find the proper mbean server in this way; they just have it injected or get it from their Container or something.

> org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4623
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: William DeCoste
>         Assigned To: Brian Stansberry
>
> MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().
> Let me know if you see what I mean - I can fix it. 
> I'm looking in Branch_4_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 lists.jboss.org  Thu Aug 23 13:12:18 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Thu, 23 Aug 2007 13:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22203962.1187889138397.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373555 ] 
            
Alexandre Gattiker commented on JBRULES-1091:
---------------------------------------------

Thanks for the tip on accumulate functions. Indeed that is what I developed in my case, though it doesn't help on the null issue of course.

I agree with your assumption, as I understand that Drools cannot handle null facts. There is not always a direct null object available, however (such as your example with Money(0), which lacks a currency). We can still use either the Null Object pattern or a mutable object (commons-lang), something like

MutableObject(value: $totalPayments:) 
   from accumulate( Payment ( customer == $c, $val : value )
                                   init( MutableObject total = new MutableObject(); )
                                   action( total.setValue(addNullSafe( $val, total.getValue()) ); )
                                   result( total ) ) 

So the bug can only be solved in catching the error early and provide a meaningful error message.

Thank you very much for your tips. Drools is so elegant it's highly addictive :)

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Thu Aug 23 14:07:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <13608425.1187892438431.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373559 ] 
            
Fernando Meyer commented on JBRULES-1112:
-----------------------------------------

Wailting for user feedback

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Thu Aug 23 14:07:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1118) Add support for
 rf, xml and dsrl into drools-ant task
Message-ID: <3609578.1187892438576.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for rf, xml and dsrl into drools-ant task 
------------------------------------------------------

                 Key: JBRULES-1118
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1118
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.1
            Reporter: Fernando Meyer
         Assigned To: Fernando Meyer


Add support for rf, xml and dsrl into drools-ant 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 lists.jboss.org  Thu Aug 23 14:11:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1028) importing .brxml
 into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16173322.1187892678449.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer closed JBRULES-1028.
-----------------------------------

    Resolution: Done

Now you can use drools-ant to compile brxml and other formats into one serialized rulebase 

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Thu Aug 23 14:23:18 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Aug 2007 14:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1033) Rationalise
 and speedup test suite
In-Reply-To: <9387617.1186598269311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13668335.1187893398218.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox closed JBMESSAGING-1033.
--------------------------------

    Resolution: Done

> Rationalise and speedup test suite
> ----------------------------------
>
>                 Key: JBMESSAGING-1033
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1033
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> After migration to Hudson - the test takes far too long to run.
> It needs to be speeded up if it is to be any use.
> The clustering, bridge and thirdparty tests do not need to be run against all databases, only the invm and remote tests 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 lists.jboss.org  Thu Aug 23 14:32:18 2007
From: jira-events at lists.jboss.org (David Stroop (JIRA))
Date: Thu, 23 Aug 2007 14:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBADMCON-114)
 java.lang.ClassCastException: java.lang.OutOfMemoryError
Message-ID: <16912543.1187893938786.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBADMCON-114?page=comments#action_12373568 ] 
            
David Stroop commented on JBADMCON-114:
---------------------------------------

Also happens with 

Client:
IE6.0.2900.2180.xpsp_sp2_gdr.070227-2254

Java Plug-in 1.6.0_02
Using JRE version 1.6.0_02 Java HotSpot(TM) Client VM

http://64.109.44.20/web-console/Invoker
java.lang.ClassCastException: java.lang.OutOfMemoryError cannot be cast to java.lang.Exception
	at org.jboss.console.remote.Util.invoke(Util.java:80)
	at org.jboss.console.remote.AppletRemoteMBeanInvoker.invoke(AppletRemoteMBeanInvoker.java:50)
	at org.jboss.console.navtree.ConsoleTreeModel.loadTree(ConsoleTreeModel.java:104)
	at org.jboss.console.navtree.ConsoleTreeModel.<init>(ConsoleTreeModel.java:59)
	at org.jboss.console.navtree.AdminTreeBrowser.<init>(AdminTreeBrowser.java:63)
	at org.jboss.console.navtree.AppletBrowser.start(AppletBrowser.java:51)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Version: 4.0.3SP1(build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)
Version Name: Zion
Built on: October 23 2005 

Server:
OS: Linux 2.6.9-34.EL (i386)
JVM Version: 1.4.2_11-b06


Left panel is blank, right panel shows:
JBoss? Application Server
JBoss 
...
JVM - Hardware 
...


> java.lang.ClassCastException: java.lang.OutOfMemoryError
> --------------------------------------------------------
>
>                 Key: JBADMCON-114
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-114
>             Project: JBoss Admin Console
>          Issue Type: Bug
>          Components: General Console
>         Environment: Server: JBoss 4.0.1sp1 running on Win2003, JDK  1.5.0_02-b09 
> Client: XP, IE / Mozilla, JDK 1.5.0-b64 / 1.5.0_02-b09
>            Reporter: Paul Kuit
>
> Applet won?t show; stacktrace;
> running local on the server
> http://localhost/web-console/Invoker
> java.lang.ClassCastException: java.lang.OutOfMemoryError
> 	at org.jboss.console.remote.Util.invoke(Util.java:80)
> 	at org.jboss.console.remote.AppletRemoteMBeanInvoker.invoke(AppletRemoteMBeanInvoker.java:50)
> 	at org.jboss.console.navtree.ConsoleTreeModel.loadTree(ConsoleTreeModel.java:104)
> 	at org.jboss.console.navtree.ConsoleTreeModel.<init>(ConsoleTreeModel.java:59)
> 	at org.jboss.console.navtree.AdminTreeBrowser.<init>(AdminTreeBrowser.java:63)
> 	at org.jboss.console.navtree.AppletBrowser.start(AppletBrowser.java:51)
> 	at sun.applet.AppletPanel.run(Unknown Source)
> 	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 lists.jboss.org  Thu Aug 23 14:47:23 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1053) Write a test
 for JBMESSAGING-1031
Message-ID: <2848037.1187894843075.JavaMail.jira@cloud.prod.atl2.jboss.com>

Write a test for JBMESSAGING-1031
---------------------------------

                 Key: JBMESSAGING-1053
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1053
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.GA


I have fixed JBMESSAGING-1031 using a manual test.. we need to add a testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:47:23 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Aug 2007 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1039) HTTP poller
	doesn't stop
In-Reply-To: <3265708.1186657442806.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30300908.1187894843267.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Tim Fox updated JBMESSAGING-1039:
---------------------------------

    Fix Version/s: 1.4.0.GA
                       (was: 1.4.0.CR2)

> HTTP poller doesn't stop
> ------------------------
>
>                 Key: JBMESSAGING-1039
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1039
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.GA
>
>
> I have temporarily commented out clusterviewupdatetst::testUpdateMixedConnectionFactory since, once started, the HTTP poller doesn't stop.
> Maybe this is a bug in remoting - need to investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:47:23 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1031) Potential bug
 in cancelling delivery
In-Reply-To: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3414986.1187894843416.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1031.
----------------------------------------

    Resolution: Done

> Potential bug in cancelling delivery
> ------------------------------------
>
>                 Key: JBMESSAGING-1031
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>         Attachments: test.patch
>
>
> Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:49:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1054) Create a test
 where a client failing with a ClusteredCF
Message-ID: <13035907.1187894958217.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a test where a client failing with a ClusteredCF
-------------------------------------------------------

                 Key: JBMESSAGING-1054
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1054
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:51:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4882515.1187895078334.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1027.
----------------------------------------

    Resolution: Done

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:53:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Aug 2007 14:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-404) Create project site
 for jboss-deploy plugin.
In-Reply-To: <27716106.1187728638760.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5728710.1187895198282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-404?page=all ]

Paul Gier closed JBBUILD-404.
-----------------------------

    Resolution: Done

Plugin now has a site here http://labs.jboss.com/maven-jboss-deploy-plugin.

> Create project site for jboss-deploy plugin.
> --------------------------------------------
>
>                 Key: JBBUILD-404
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-404
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: maven-jboss-deploy-plugin
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> There should be a project site that contains documentation for the plugin on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:55:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 14:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
In-Reply-To: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26152294.1187895318507.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste updated JBAS-4623:
----------------------------------

    Priority: Minor  (was: Major)

> org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4623
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: William DeCoste
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().
> Let me know if you see what I mean - I can fix it. 
> I'm looking in Branch_4_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 lists.jboss.org  Thu Aug 23 14:59:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1105) web.xml does not
 conform web-app_2_3.dtd
In-Reply-To: <3916092.1187585177133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1786072.1187895558428.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer closed JBRULES-1105.
-----------------------------------

    Resolution: Done

element order does matter in web.xml 

> web.xml does not conform web-app_2_3.dtd
> ----------------------------------------
>
>                 Key: JBRULES-1105
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1105
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Glassfish
>            Reporter: Michael Max
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> web.xml does not comply with a http://java.sun.com/dtd/web-app_2_3.dtd specification. Because of that drools-jbrms.war cannot be deployed to the servers with a strict validation as Glassfish, just to JBoss AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 15:19:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 15:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4615) NamingContext caches
 stale Naming stub
In-Reply-To: <17323116.1187577725144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32886719.1187896758277.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry closed JBAS-4615.
----------------------------------

    Resolution: Done

> NamingContext caches stale Naming stub
> --------------------------------------
>
>                 Key: JBAS-4615
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4615
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> As an important performance optimization, org.jnp.interfaces.NamingContext statically caches a WeakReference to the "proxy" to the server-side Naming service.  In most cases this is either an RMI stub (non-HA naming service) or a proxy based on an HARMIClient (for HA-JNDI).  Either way, the cached object uses RMI to communicate with the server.
> This object becomes invalid if the server (non-HA case) or cluster (HA case) it was associated with is restarted.  The object in the restarted server-side RMI runtime will no longer match the client-side RMI stub, and an invocation over the stub will result in a java.rmi.NoSuchObjectException on the client.  NamingContext's caching of the RMI greatly increases the odds of this occuring.  If this occurs, the cache will be flushed and the next call will acquire a fresh stub from the server, but the client will get an exception on the first call.
> Proposed solution is discussed on forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 15:21:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 15:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4553) Organize cluster
 testsuite package
 to allow easy ant patternset control of what runs under what configs
In-Reply-To: <22873919.1184512683856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <350491.1187896878223.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry closed JBAS-4553.
----------------------------------

    Resolution: Done

> Organize cluster testsuite package to allow easy ant patternset control of what runs under what configs
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4553
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4553
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 15:23:18 2007
From: jira-events at lists.jboss.org (sdf sdf (JIRA))
Date: Thu, 23 Aug 2007 15:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1047) Need APIs on
 BusinessCalendar for setting values that are currently supplied via
 jbpm.business.calendar.properties file.
Message-ID: <13562311.1187896998257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Need  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.
-------------------------------------------------------------------------------------------------------------------------

                 Key: JBPM-1047
                 URL: http://jira.jboss.com/jira/browse/JBPM-1047
             Project: JBoss jBPM
          Issue Type: Feature Request
            Reporter: sdf sdf
         Assigned To: Tom Baeyens


Holidays, business hours are currently supplied to JBPM via a properties file. It would be nice to have a programattic way to add, modify these without having to edit the properties 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 lists.jboss.org  Thu Aug 23 15:53:22 2007
From: jira-events at lists.jboss.org (Davy Toch (JIRA))
Date: Thu, 23 Aug 2007 15:53:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
Message-ID: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>

"ExpanderResolver was not set" when DSL and DRL in separate resource folders.
-----------------------------------------------------------------------------

                 Key: JBRULES-1119
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 3.0.5
         Environment: - Eclipse 3.2.1
- WinXP
            Reporter: Davy Toch
         Assigned To: Mark Proctor
            Priority: Minor
         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip


1. jbossrulesproject_one_resource_folder.zip

- DRL and DSL in one resource folder
- no problem

2. jbossrulesproject_two_resource_folders.zip

- DRL and DSL in separate resource folders
- causes error message : "ExpanderResolver was not set"

We actually prefer two separate resource folders, because the rules are generated during the ANT
build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
in 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 lists.jboss.org  Thu Aug 23 15:53:22 2007
From: jira-events at lists.jboss.org (Davy Toch (JIRA))
Date: Thu, 23 Aug 2007 15:53:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16475217.1187898802666.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Davy Toch updated JBRULES-1119:
-------------------------------

    Attachment: jbossrulesproject_one_resource_folder.zip

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Mark Proctor
>            Priority: Minor
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Thu Aug 23 15:53:22 2007
From: jira-events at lists.jboss.org (Davy Toch (JIRA))
Date: Thu, 23 Aug 2007 15:53:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25459052.1187898802839.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Davy Toch updated JBRULES-1119:
-------------------------------

    Attachment: jbossrulesproject_two_resource_folders.zip

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Mark Proctor
>            Priority: Minor
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Thu Aug 23 15:59:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Thu, 23 Aug 2007 15:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1063) Failing location
 determination tests
In-Reply-To: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19434154.1187899158395.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne reassigned JBRULES-1063:
--------------------------------------------

    Assignee: Kris Verlaenen  (was: Edson Tirelli)

Kris:
Could you review this?
I just would like you to review the two test quickly (the FAILING ones are the original ones) : http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14055#l212 

and here : 
http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14055#l1736

Th is about a change in whitespace handling that was introduced in eth paers.
I am not sure what are the implications for that.
I copied the 2 tests that failed, and made them pass (not whitespace at the end of the line) and kept the ones that failed prefixed with FAILING 

> Failing location determination tests
> ------------------------------------
>
>                 Key: JBRULES-1063
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Kris Verlaenen
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  
> Their name is prefixed with FAILING
> I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
> The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 16:01:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Aug 2007 16:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-407) Migrate
 microcontainer docbook gen to jdocbook plugin
Message-ID: <26415361.1187899278199.JavaMail.jira@cloud.prod.atl2.jboss.com>

Migrate microcontainer docbook gen to jdocbook plugin
-----------------------------------------------------

                 Key: JBBUILD-407
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-407
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Microcontainer should use the maven-jdocbook-plugin for it's doc generation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:08:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 23 Aug 2007 17:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4626) Javassist 3.6.0.CR1
Message-ID: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>

Javassist 3.6.0.CR1
-------------------

                 Key: JBAS-4626
                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:12:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 17:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1120) Implement Step
 Over for mvel debugger
Message-ID: <426588.1187903538246.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement Step Over for mvel debugger
-------------------------------------

                 Key: JBRULES-1120
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1120
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Ahti Kitsik
         Assigned To: Ahti Kitsik
             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 17:12:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 17:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-76) SecurityAssociation
 CallerPrincipal
Message-ID: <11020680.1187903538403.JavaMail.jira@cloud.prod.atl2.jboss.com>

SecurityAssociation CallerPrincipal
-----------------------------------

                 Key: SECURITY-76
                 URL: http://jira.jboss.com/jira/browse/SECURITY-76
             Project: JBoss Security and Identity Management
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0.1-BETA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1-GA


SecurityAssociation.getCallerPrincipal needs to return the principal from 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 lists.jboss.org  Thu Aug 23 17:14:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 17:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1120) Implement Step
 Over for mvel debugger
In-Reply-To: <426588.1187903538246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5219930.1187903658293.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ahti Kitsik resolved JBRULES-1120.
----------------------------------

    Resolution: Done
      Assignee: Mark Proctor  (was: Ahti Kitsik)

done.

> Implement Step Over for mvel debugger
> -------------------------------------
>
>                 Key: JBRULES-1120
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1120
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Ahti Kitsik
>         Assigned To: Mark Proctor
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 17:19:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 17:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-76)
 SecurityAssociation and SecurityContext linkage
In-Reply-To: <11020680.1187903538403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27409513.1187903958223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-76?page=all ]

Anil Saldhana updated SECURITY-76:
----------------------------------

        Summary: SecurityAssociation and SecurityContext linkage  (was: SecurityAssociation CallerPrincipal)
    Description: 
SecurityAssociation.getCallerPrincipal needs to return the principal from the security context

Also setPrincipal and setCredential needs to be verified.

  was:SecurityAssociation.getCallerPrincipal needs to return the principal from the security context


> SecurityAssociation and SecurityContext linkage
> -----------------------------------------------
>
>                 Key: SECURITY-76
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-76
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.1-BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1-GA
>
>
> SecurityAssociation.getCallerPrincipal needs to return the principal from the security context
> Also setPrincipal and setCredential needs to be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:27:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 17:27:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-76) SecurityAssociation
 and SecurityContext linkage
In-Reply-To: <11020680.1187903538403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8240283.1187904438234.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-76?page=all ]

Anil Saldhana closed SECURITY-76.
---------------------------------

    Resolution: Done

Running org.jboss.test.securityassociation.LegacySecurityAssociationTestCase
Found log4j.xml: file:/C:/cygwin/home/asaldhana/security/security-jboss-sx/trunk/target/test-classes/log4j.xml
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec

> SecurityAssociation and SecurityContext linkage
> -----------------------------------------------
>
>                 Key: SECURITY-76
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-76
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.1-BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1-GA
>
>
> SecurityAssociation.getCallerPrincipal needs to return the principal from the security context
> Also setPrincipal and setCredential needs to be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:29:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 17:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1038) Client side
 failover hopping does not work
In-Reply-To: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24346462.1187904558807.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1038.
----------------------------------------

    Resolution: Done

> Client side failover hopping does not work
> ------------------------------------------
>
>                 Key: JBMESSAGING-1038
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.
> if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".
> Instead it should iterate through the list of delegates trying each one in turn.
> Need to write a test for this 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 lists.jboss.org  Thu Aug 23 17:59:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 23 Aug 2007 17:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4626) Javassist 3.6.0.CR1
In-Reply-To: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5858748.1187906358244.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kabir Khan closed JBAS-4626.
----------------------------

    Resolution: Done

> Javassist 3.6.0.CR1
> -------------------
>
>                 Key: JBAS-4626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:20:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 18:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8785697.1187907618346.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli closed JBRULES-1091.
----------------------------------

    Resolution: Done

Ok, I added integration tests and null handling code in accumulate. Now if accumulate ever returns a null value, it will raise a RuntimeDroolsException with appropriate message.

Thanks for reporting.

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Thu Aug 23 18:22:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 18:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1055) Previously
 downloaded ConnectionFactory can't be used after restart
Message-ID: <13862907.1187907738589.JavaMail.jira@cloud.prod.atl2.jboss.com>

Previously downloaded ConnectionFactory can't be used after restart
-------------------------------------------------------------------

                 Key: JBMESSAGING-1055
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1055
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR1
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1055) Previously
 downloaded ConnectionFactory can't be used after restart
In-Reply-To: <13862907.1187907738589.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12524778.1187907858405.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1055.
----------------------------------------

    Resolution: Done

> Previously downloaded ConnectionFactory can't be used after restart
> -------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1055
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1055
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:24:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4552) Move all cluster
 tests under the org.jboss.test.cluster package
In-Reply-To: <896060.1184512683733.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16278192.1187907858819.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry closed JBAS-4552.
----------------------------------

    Resolution: Done

> Move all cluster tests under the org.jboss.test.cluster package
> ---------------------------------------------------------------
>
>                 Key: JBAS-4552
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4552
>             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
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Get all the tests together for easier management.
> org.jboss.test.ha.farm
> org.jboss.test.ha.jmx
> org.jboss.test.testbeancluster
> org.jboss.test.cache

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:24:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4551) Rationalize
	clustering testsuite
In-Reply-To: <15876970.1184512455093.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32601968.1187907858951.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry closed JBAS-4551.
----------------------------------

    Resolution: Done

> Rationalize clustering testsuite
> --------------------------------
>
>                 Key: JBAS-4551
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4551
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Container task for reorganize discussed on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113548.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:32:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 18:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4401) Clustering unit
 test failures - UDP stack
In-Reply-To: <4622729.1178507222526.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13999345.1187908338286.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry resolved JBAS-4401.
------------------------------------

    Resolution: Incomplete Description

Resolving due to no response on what release or branch this issue is reported against.

> Clustering unit test failures - UDP stack
> -----------------------------------------
>
>                 Key: JBAS-4401
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4401
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: xiangyang wang
>         Assigned To: Brian Stansberry
>
> Resolve remaining clustering related unit test failures.  The testbeancluster.BeanClusterUnitTestCase.testStatefulPassiviationExpiration test needs to be made more robust.  On the http session cases, the teardown needs to allow enough time for session invalidation to propagate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 19:04:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1069) DSL sentence
 widget is too
 small and combobox with sentences should not be expanded
In-Reply-To: <21523644.1186685221254.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6933132.1187910258353.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ahti Kitsik closed JBRULES-1069.
--------------------------------

    Resolution: Done

> DSL sentence widget is too small and combobox with sentences should not be expanded
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-1069
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1069
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Ahti Kitsik
>         Assigned To: Ahti Kitsik
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Reported by Kris Verlaenen:
> There is still an issue with DSL in the guided editor:
> if you add a DSL sentence, fill in some values, and then try to add
> more sentences, the sentences shown in the drop-down box also contain
> the filled in values ?
> The size of the boxes in DSL sentences also seem to shrink to minimal
> when adding new sentences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 19:04:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1052) When Inserting a
 fact cannot set a String field
In-Reply-To: <1292464.1185911829398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4598699.1187910258806.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ahti Kitsik closed JBRULES-1052.
--------------------------------

    Resolution: Done

> When Inserting a fact cannot set a String field
> -----------------------------------------------
>
>                 Key: JBRULES-1052
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1052
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> A String field only let me put in numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 19:04:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1120) Implement Step
 Over for mvel debugger
In-Reply-To: <426588.1187903538246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4917728.1187910258925.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ahti Kitsik closed JBRULES-1120.
--------------------------------

    Assignee: Ahti Kitsik  (was: Mark Proctor)

> Implement Step Over for mvel debugger
> -------------------------------------
>
>                 Key: JBRULES-1120
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1120
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Ahti Kitsik
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 20:04:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 20:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1038) several classes
 check for RemoteBinding or RemoteBindings but not both
Message-ID: <17120176.1187913858226.JavaMail.jira@cloud.prod.atl2.jboss.com>

several classes check for RemoteBinding or RemoteBindings but not both
----------------------------------------------------------------------

                 Key: EJBTHREE-1038
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1038
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1
            Reporter: William DeCoste
         Assigned To: William DeCoste
            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 lists.jboss.org  Thu Aug 23 21:05:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 21:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1012)
 SeveralClientsStressTest leads to remoting dead lock
In-Reply-To: <18706398.1184093551579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10721464.1187917518500.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1012.
----------------------------------------

    Resolution: Done

I have executed the test several times, and didn't fail...

I have also executed the test for an hour (changing few parameters on the test), and the test supported the huge ammount of load.

> SeveralClientsStressTest leads to remoting dead lock
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1012
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1012
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.4.0.CR2
>
>
> SeveralClientsStressTest is not working...
> It looks like a racing between Timeouts and client.disconnect...
> Sometimes it fails, sometimes it locks 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 lists.jboss.org  Thu Aug 23 21:38:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 21:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26299815.1187919498444.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste reassigned EJBTHREE-1025:
-----------------------------------------

    Assignee: William DeCoste  (was: Carlo de Wolf)

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 22:26:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 22:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8602225.1187922378546.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12373623 ] 
            
William DeCoste commented on EJBTHREE-1025:
-------------------------------------------

This is fixed in Branch_4_2. Do we want to port it to JBPAPP branches or just 5.0?

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:42:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25492749.1187926938459.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I'm pretty sure this is fixed. Stateless Session was not inserting the InitialFact. I'll add an integration for this, just in case.

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:44:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1104) Inserted
 Objects are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12731234.1187927058203.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

This was slightly mistaken, internal Objects where lost, like InitialFactImpl

> Inserted Objects are lost if no matching ObjectTypeNodes
> --------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:46:25 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:46:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1104) Inserted internal
 Objects
 (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13727001.1187927185922.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1104:
----------------------------------

    Summary: Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes  (was: Inserted Objects are lost if no matching ObjectTypeNodes)

> Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:48:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1104) Inserted internal
 Objects (like
 InitialFactImpl)  are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7085099.1187927298197.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1104.
---------------------------------

    Resolution: Done

> Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:52:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1104) Inserted
 internal Objects
 (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24332203.1187927538347.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

The main things it does is create an ObjectTypeNode for an inserted object, if one does not exist for it. When a new ObjectTypenode is added the updateSink now just iterates the ObjectTypeConf (only exists for inserted conrete types) and pushes through the data from any matching ObjectTypeNodes - it also resets the cache on just those. So it no longer iterates the entire working memory and it selectively resets the cache.

> Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:01:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 00:01:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27879599.1187928079949.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1119:
----------------------------------

    Fix Version/s: 4.0.1
      Description: 
1. jbossrulesproject_one_resource_folder.zip

- DRL and DSL in one resource folder
- no problem

2. jbossrulesproject_two_resource_folders.zip

- DRL and DSL in separate resource folders
- causes error message : "ExpanderResolver was not set"

We actually prefer two separate resource folders, because the rules are generated during the ANT
build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
in src/...).

  was:

1. jbossrulesproject_one_resource_folder.zip

- DRL and DSL in one resource folder
- no problem

2. jbossrulesproject_two_resource_folders.zip

- DRL and DSL in separate resource folders
- causes error message : "ExpanderResolver was not set"

We actually prefer two separate resource folders, because the rules are generated during the ANT
build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
in src/...).

         Assignee: Michael Neale  (was: Mark Proctor)

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: 4.0.1
>
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Fri Aug 24 00:03:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 00:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20026611.1187928198354.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1109:
----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Michael Neale  (was: Fernando Meyer)

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:05:53 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 00:05:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17260217.1187928353935.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1106:
----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Michael Neale  (was: Mark Proctor)

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:05:54 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Fri, 24 Aug 2007 00:05:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <500544.1187928354086.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1109?page=comments#action_12373631 ] 
            
Michael Neale commented on JBRULES-1109:
----------------------------------------

This is according to the JCR spec (I think) - it is stated also in the manual that the version history is not supported (the GUI said backup/restore - which is not technically correct).

Will look into ways to achieve this, but I am not sure if there is an easy way at hand. 

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:16:35 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Fri, 24 Aug 2007 00:16:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10048802.1187928995468.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1106?page=comments#action_12373632 ] 
            
Michael Neale commented on JBRULES-1106:
----------------------------------------

Hmmm yes - I think the name of the rule in the drl shoudl be the name of the asset - not whatever it things it was from the old rule (ie it is copying the name across to the new name - not really that helpful !). well spotted !

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 02:39:29 2007
From: jira-events at lists.jboss.org (sreeni sabapathy (JIRA))
Date: Fri, 24 Aug 2007 02:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1121) Operator field
 and the fact's
 variable field required in the "then" part of the rule
Message-ID: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>

Operator field and the fact's variable field required in the "then" part of the rule
------------------------------------------------------------------------------------

                 Key: JBRULES-1121
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-brms, Eclipse IDE
    Affects Versions:  4.0.0.GA
         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
            Reporter: sreeni sabapathy
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
But in many condition the the value of the variable depends upon the value of another variable.

I have taken  a simple example for explanation.

For calcluating simple interest

SI = P*T*R/100

Now in the rule file if the 

"when" condition as the check of " Calcluation type (simple ineterst or compound interest)"

"then" part having SI, 

At the present drool-jbrms definition the 

"then" part has SI = text field.

But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
assign some fixed values.

In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 03:07:18 2007
From: jira-events at lists.jboss.org (Gabriele Garuglieri (JIRA))
Date: Fri, 24 Aug 2007 03:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1037)
 JDBCPersistenceManager.java - reference should be inserted after message
 (ORA-02291: integrity constraint)
In-Reply-To: <21939514.1186653049587.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31914048.1187939238941.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1037?page=comments#action_12373635 ] 
            
Gabriele Garuglieri commented on JBMESSAGING-1037:
--------------------------------------------------

Being bitten by the same problem with Postgres.
1.4.0.CR1 looks to be completely unusable because it fails with constraint violation as soon as i try to send a message.

> JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1037
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>         Environment: Windows XP / Oracle 10g
>            Reporter: Mariusz Olejnik
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.4.0.CR1
>
>         Attachments: jboss-messaging-trunk-rev2988.patch
>
>
> Reference should be inserted after message because:
> oracle-persistence-service.xml 
> CREATE TABLE JBM_MSG_REF (
>   CHANNEL_ID INTEGER, 
>   MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) 
> [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 03:25:20 2007
From: jira-events at lists.jboss.org (Gabriele Garuglieri (JIRA))
Date: Fri, 24 Aug 2007 03:25:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1056) JBM_MSG_REF
 table must be created after JBM_MSG
Message-ID: <13693640.1187940320838.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBM_MSG_REF table must be created after JBM_MSG
-----------------------------------------------

                 Key: JBMESSAGING-1056
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1056
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
         Environment: Java 1.6.0_02-b06
JBoss 4.2.1.GA
Jbmessaging 1.4.0.CR1
PostgreSQL 8.2.4
            Reporter: Gabriele Garuglieri
         Assigned To: Tim Fox


At the first startup on a clean db the creation of JBM_MSG_REF table fails with error:
org.postgresql.util.PSQLException: ERROR: relation "jbm_msg" does not exist
because it now has a relation with JBM_MSG table that is not yet created.
The situation gets cleaned up after a restart because on the second run it finds JBM_MSG table and is able to proceed with JBM_MSG_REF table creation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 04:08:18 2007
From: jira-events at lists.jboss.org (gerald zhou (JIRA))
Date: Fri, 24 Aug 2007 04:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1057)
 java.io.IOException:
 EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment
Message-ID: <17912445.1187942898273.JavaMail.jira@cloud.prod.atl2.jboss.com>

java.io.IOException: EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment
-------------------------------------------------------------------------------

                 Key: JBMESSAGING-1057
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1057
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Remoting
    Affects Versions: 1.2.0.SP1
         Environment: boss-4.0.5.GA, java 1.4.2_07 , jboss messaging 1.2.0.SP1
            Reporter: gerald zhou
         Assigned To: Tim Fox


java.io.IOException: EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
        at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
        at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:367)
        at EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap.writeObject(Unknown Source)
        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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
        at org.jboss.jms.wireformat.SerializedPacket.write(SerializedPacket.java:80)
        at org.jboss.jms.server.remoting.JMSWireFormat.write(JMSWireFormat.java:245)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:958)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:552)
        at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:339)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
        at org.jboss.remoting.LeasePinger.sendClientPing(LeasePinger.java:283)
        at org.jboss.remoting.LeasePinger.access$000(LeasePinger.java:20)
        at org.jboss.remoting.LeasePinger$LeaseTimerTask.run(LeasePinger.java:315)
        at java.util.TimerThread.mainLoop(Timer.java:432)
        at java.util.TimerThread.run(Timer.java:382)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 04:22:18 2007
From: jira-events at lists.jboss.org (dana enescu (JIRA))
Date: Fri, 24 Aug 2007 04:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1169) some methods in
 eviction queue
 classes have package-only visibility - can it be changed?
Message-ID: <31734798.1187943738292.JavaMail.jira@cloud.prod.atl2.jboss.com>

some methods in eviction queue classes have package-only visibility - can it be changed?
----------------------------------------------------------------------------------------

                 Key: JBCACHE-1169
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1169
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eviction
    Affects Versions: 2.0.0.GA
            Reporter: dana enescu
         Assigned To: Manik Surtani
            Priority: Minor


I have been trying to implement my own cache eviction policy. The most convenient way for me was to extend LFU, instead of implementing the interfaces from scratch.
However, the ctor and the prune() method in LFUQueue have package-only visibility, so I had to do a nasty workaround. There may be similar issues in other classes of the eviction package. 

IMO it would be better that these methods are made either public or protected, depending on what you want to expose to the users. I did not report it as a bug but rather as a feature request, since I do not know the developer's intent.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 05:47:02 2007
From: jira-events at lists.jboss.org (Suman Ghosh (JIRA))
Date: Fri, 24 Aug 2007 05:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1122) Eclipse-JDT
 compiler jar
 (core-3.2.0.666.jar) for drools creates problems/conflicts with the
 existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
Message-ID: <527189.1187948822233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eclipse-JDT compiler jar (core-3.2.0.666.jar) for drools creates problems/conflicts with the existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1122
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1122
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA, 3.0.6
         Environment: Windows XP / JDK 1.5.0_06-b05
            Reporter: Suman Ghosh
         Assigned To: Mark Proctor


I'm running a service using JBoss, which uses Drools for its various rule-based components. The propblem arises like this -  when I use the JDTcompiler in Drools, tomcat crashes with the following stacktrace (when used to access JSPs - such as the JBoss JMX console)....

----------------------------------------------------START-------------------------------------------------------------------
type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:272)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

root cause

java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
	org.apache.jasper.compiler.JDTCompiler$2.acceptResult(JDTCompiler.java:345)
	org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417)
	org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:404)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:297)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
---------------------------------------------------END--------------------------------------------------------------------

Seems that the class CompilationResult from the new JDT distribution has a different signature for the getProblems() method - but tomcat expects the earlier one only.

For my application, I *have* to use the JDT compiler for my rule base, and on the other hand, I require the jboss jmx-console, for service monitoring and method invokations :(

Please suggest a solution!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 05:53:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 24 Aug 2007 05:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1063) Failing location
 determination tests
In-Reply-To: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9025771.1187949198716.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen resolved JBRULES-1063.
-------------------------------------

    Resolution: Done

Updated location determination to fix tests

> Failing location determination tests
> ------------------------------------
>
>                 Key: JBRULES-1063
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Kris Verlaenen
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  
> Their name is prefixed with FAILING
> I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
> The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 05:57:39 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 24 Aug 2007 05:57:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17480318.1187949459928.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen resolved JBRULES-1048.
-------------------------------------

    Resolution: Done

Renamed *.drl using dsl to *.dslr

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Fri Aug 24 06:17:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 24 Aug 2007 06:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1047) Provice APIs on
 BusinessCalendar for setting values that are currently supplied via
 jbpm.business.calendar.properties file.
In-Reply-To: <13562311.1187896998257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12936147.1187950638351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1047?page=all ]

Ronald van Kuijk updated JBPM-1047:
-----------------------------------

              Summary: Provice  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.  (was: Need  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.)
          Component/s: Core Engine
        Fix Version/s: jBPM 4.0
    Affects Version/s:  jBPM jPDL 3.2.1
             Priority: Optional  (was: Major)

Please be a little more specific.... 

> Provice  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1047
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1047
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: sdf sdf
>         Assigned To: Tom Baeyens
>            Priority: Optional
>             Fix For: jBPM 4.0
>
>
> Holidays, business hours are currently supplied to JBPM via a properties file. It would be nice to have a programattic way to add, modify these without having to edit the properties 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 lists.jboss.org  Fri Aug 24 07:41:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 07:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-455) Upgrade javassist to
	3.6.0.CR2
Message-ID: <22621436.1187955678243.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade javassist to 3.6.0.CR2
------------------------------

                 Key: JBAOP-455
                 URL: http://jira.jboss.com/jira/browse/JBAOP-455
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.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 lists.jboss.org  Fri Aug 24 07:43:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 07:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-454) Upgrade jboss retro
	to 1.1.2
In-Reply-To: <31251926.1187351581112.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29970387.1187955798288.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-454?page=all ]

Kabir Khan closed JBAOP-454.
----------------------------

    Resolution: Done
      Assignee: Kabir Khan  (was: Flavia Rainone)

Build and install scripts have been modified to use the right names (this version of retro uses different names for the jars than previously)

> Upgrade jboss retro to 1.1.2
> ----------------------------
>
>                 Key: JBAOP-454
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-454
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.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 lists.jboss.org  Fri Aug 24 07:49:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 07:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26063458.1187956158394.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

This was fixed as part of  JBRULES-1104, I've added the unit test anyway to catch future regressions.

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 07:49:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 07:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1116) "not" doesn't work
 for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31735536.1187956158588.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1116.
---------------------------------

    Resolution: Done

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 07:58:29 2007
From: jira-events at lists.jboss.org (Gokhan Demir (JIRA))
Date: Fri, 24 Aug 2007 07:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4609) Original
 SevletResponse or
 wrapped original ServletResponse not passed to RequestDispatcher in
 violation of SRV.8.2 and SRV.14.2.5.1
In-Reply-To: <14152110.1187166841533.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29643548.1187956709912.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4609?page=comments#action_12373670 ] 
            
Gokhan Demir commented on JBAS-4609:
------------------------------------

The same error happening in my production web application, for version 4.2.1.GA. It is not reproducable, just randomly happening.

> Original SevletResponse or wrapped original ServletResponse not passed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4609
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4609
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: RHeL
>            Reporter: stefan lotties
>
> Sometimes in the log the following stacktrace appears while someone is surfing in an application:
> 2007-08-09 12:10:01,834 [http-0.0.0.0-8080-1] ERROR org.apache.catalina.core.ContainerBase.[jboss.we
> b].[localhost].[/webadmin].[action] - Servlet.service() for servlet action threw exception
> javax.servlet.ServletException: Original SevletResponse or wrapped original ServletResponse not pass
> ed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
>         at org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.jav
> a:1018)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:329)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056)
>         at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261)
>         at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcesso
> r.java:237)
>         at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.
> java:300)
>         at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231)
>         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
>         at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
>         at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:271)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
> ava:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
>         at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:
> 469)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.
> java:316)
>         at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:2
> 44)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:
> 156)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
> va:580)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595) 
> I debugged as far as I could and noticed that the http-request returns the host the jboss runs on when calling HttpServletRequest.getRemoteHost() and has "HEAD" as method. It can't be reproduced since it seems to be kinda random (doing the same action twice or more often does not end in this exception). Also the requested-URIs are different. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 09:04:35 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:04:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
Message-ID: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>

Timer task throws exception on task submission if task has already been cancelled
---------------------------------------------------------------------------------

                 Key: JGRP-582
                 URL: http://jira.jboss.com/jira/browse/JGRP-582
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5.1, 2.6


When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
SOLUTION: simply catch and eat the exception

@FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
java.lang.IllegalStateException: Timer already cancelled.
        at java.util.Timer.sched(Timer.java:354)
        at java.util.Timer.schedule(Timer.java:170)
        at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
        at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
        at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
        at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
        at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
        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 lists.jboss.org  Fri Aug 24 09:11:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26093651.1187961078448.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Note that this can also happen if we submit a task to a timer that has already been cancelled

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:13:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9324642.1187961198294.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-582:
--------------------------

    Fix Version/s: 2.4.1 SP5

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1, 2.4.1 SP5
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:16:11 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19921189.1187961371958.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

We don't need to fix this in 2.5 and 2.6

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1, 2.4.1 SP5
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:16:12 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:16:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10652112.1187961372074.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-582.
---------------------------

    Resolution: Done

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4.1 SP5, 2.5.1, 2.6
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:56:18 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Fri, 24 Aug 2007 09:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1167) Heuristic outcome
 (STATUS_UNKNOWN) of transaction not handled properly
In-Reply-To: <9760798.1187716218788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24294005.1187963778285.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1167?page=all ]

Manik Surtani closed JBCACHE-1167.
----------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-1167
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1167
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP4, 2.0.0.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.SP5, 2.1.0.GA
>
>
> Where an XA transaction has a heuristic outcome, the status reported to 
> the afterCompletion synchronization is STATUS_UNKNOWN (5), since 
> JTA does not handle heuristics. In this case, the cache Synchronization 
> fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked) 
> state even though the XA transaction has been resolved. 
> At first glance it looks like the afterCompletion synchronization should treat a 
> STATUS_UNKNOWN as a cause for rollback as well as logging the error as 
> they currently do. Unfortunately the fix may be more complex than that, since 
> the db may have committed rather than rolled back, meaning the cache would 
> be out of sync with the db if you rolled it 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 lists.jboss.org  Fri Aug 24 10:06:18 2007
From: jira-events at lists.jboss.org (Jiri Pechanec (JIRA))
Date: Fri, 24 Aug 2007 10:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1058) Table
 jbm_msg_ref constraint violation
Message-ID: <31519789.1187964378345.JavaMail.jira@cloud.prod.atl2.jboss.com>

Table jbm_msg_ref constraint violation
--------------------------------------

                 Key: JBMESSAGING-1058
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1058
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
         Environment: RHEL 5, PostgreSQL 8.2, JBoss ESB
            Reporter: Jiri Pechanec
         Assigned To: Tim Fox
            Priority: Critical


When trying to send a message I am getting exception
17:04:35,127 WARN  [JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
org.postgresql.util.PSQLException: ERROR: insert or update on table "jbm_msg_ref" violates foreign key constraint "jbm_msg_ref_message_id_fkey"
  Detail: Key (message_id)=(8192) is not present in table "jbm_msg".
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1525)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1309)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:308)
        at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2915)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2786)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1284)
        at org.jboss.messaging.core.impl.ChannelSupport.handleInternal(ChannelSupport.java:613)
        at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:148)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2101)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:505)
        at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:707)
        at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:343)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:80)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
        at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:152)
        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.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
        at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
        at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:85)
        at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 10:26:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 10:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15518639.1187965578283.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer updated JBRULES-1119:
------------------------------------

       Issue Type: Feature Request  (was: Bug)
    Fix Version/s: FUTURE
                       (was: 4.0.1)

It's not a bug, It's more an enhancement request. I will left it opened for future versions

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Fri Aug 24 10:35:33 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 10:35:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <15722408.1187966133086.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer updated JBRULES-1112:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 10:35:33 2007
From: jira-events at lists.jboss.org (Huishan Zhou (JIRA))
Date: Fri, 24 Aug 2007 10:35:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <8810911.1187966133314.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Huishan Zhou updated JBRULES-1112:
----------------------------------

    Fix Version/s: 4.0.1
                       (was: FUTURE)

I didn't find jboss-faces.jar inside JBoss4.0.5.  I searched the internet, and find it from
http://www.icefaces.org/JForum/posts/downloadAttach/1321.page together with the other
two files jsf-impl.jar and jsf-api.jar.

I add these three jars to WEB-INF/lib to test drools-jbrms.war in both  "single Jetty-6.1.1", and "JBoss-4.0.5GA bundled with Jetty-6.1.1".

They still have the problem (error message can be provided on request).  Please send me your three jar files, so that I can test your three jars with drools-jbrms.war.

We can only find lower version of JBoss bundled with Jetty in your website.  We create JBoss-4.0.5-GA bundled with Jetty-6.1.1 ourselves because we need some special features of Jetty6.1.1.
But we create this bundle based on the instruction provided by your website and Jetty.

We can contribute this bundle to you if you need.  This bundle works fine with many other examples, and has special features of working with continuation and cometd.  But this bundle also has some problems in a few other examples such as drools-jbrms.war.

Please beaware that in the selection on affected version of this page, the highest version is 4.0.1. there is no place for version 4.0.5 which is also not the future version since this version already existed on your site.



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 10:56:18 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 24 Aug 2007 10:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-151) entries in mail node
 subject and
 body elements disappear depending on click order before save
Message-ID: <17748603.1187967378477.JavaMail.jira@cloud.prod.atl2.jboss.com>

entries in mail node subject and body elements disappear depending on click order before save
---------------------------------------------------------------------------------------------

                 Key: GPD-151
                 URL: http://jira.jboss.com/jira/browse/GPD-151
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: os x, eclipse 3.3.0, 
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Critical


when I enter text in a mail node 'subject' input box, if I just click straight on the save button in eclipse, I lose the text entered...
the same is true of the 'body' input box on the mail node

to get this process to work I need to enter my text in the 'subject' input box, then click on the body input box, then click on the save button on the toolbar, this ensures my entry is in fact saved



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 11:27:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 11:27:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28876930.1187969238722.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1109?page=comments#action_12373711 ] 
            
Fernando Meyer commented on JBRULES-1109:
-----------------------------------------

Michale is right the JCR doesn't keep node version history, I will leave it for future version 

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 11:29:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 11:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16595011.1187969358471.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer updated JBRULES-1109:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: FUTURE
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 11:43:18 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 24 Aug 2007 11:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-181) ManagedObject
	support
In-Reply-To: <29484599.1183399437650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30810657.1187970198505.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Scott M Stark reassigned JBMICROCONT-181:
-----------------------------------------

    Assignee: Scott M Stark  (was: Adrian Brock)

> ManagedObject support
> ---------------------
>
>                 Key: JBMICROCONT-181
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-181
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Scott M Stark
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Add support for creating ManagedObjects 
> 1) From annotations on classes
> 2) By overrides from xml/other mechanisms
> Support different ManagedObject use cases, e.g. 
> * flat model - simple 
> * flattening model - multiple classes in (multiple) trees of object appear as one flat model
> * sets/maps/collections etc.
> * annotations
> * 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 lists.jboss.org  Fri Aug 24 11:45:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1170) Partial state
 transfer fails when multiple regions present
Message-ID: <5358429.1187970318264.JavaMail.jira@cloud.prod.atl2.jboss.com>

Partial state transfer fails when multiple regions present
----------------------------------------------------------

                 Key: JBCACHE-1170
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1170
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani


The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  

Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:

2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state

The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped".

Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:

1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.

2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should 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 lists.jboss.org  Fri Aug 24 12:02:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 12:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <17669341.1187971338528.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373721 ] 
            
Fernando Meyer commented on JBRULES-1112:
-----------------------------------------

The main difference I can see is that you putting jars into WEB-INF/lib and Im putting jar into the app server lib directory 
also did you get a fresh brms war from downloadspage ? with no changed files? 

Use the latest BRMS version from here. 
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules/drools-4.0.1.SNAPSHOT-brms.zip



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 12:04:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 12:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1170) Partial state
 transfer fails when multiple regions present
In-Reply-To: <5358429.1187970318264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31124790.1187971458782.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1170?page=all ]

Brian Stansberry updated JBCACHE-1170:
--------------------------------------

    Description: 
The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  

Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:

2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state

The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all.

Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:

1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.

2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should work.

  was:
The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  

Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:

2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state

The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped".

Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:

1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.

2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should work.


> Partial state transfer fails when multiple regions present
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1170
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1170
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>
> The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  
> Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state
> The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all.
> Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:
> 1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.
> 2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should 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 lists.jboss.org  Fri Aug 24 12:08:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 12:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <16177178.1187971698373.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer updated JBRULES-1112:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

Its not a bug, I some configuration issue.  4.0.1 is outing today so I will leave open for FUTURE assignment  I sill need two things, a bundle to integrate with jboss for test, the jetty website is down today (sic), when its online theres no valid  bundle for jboss. The other one, please test with a fresh jetty server running standalone. 

Fernando



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: FUTURE
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 12:20:20 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 12:20:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4546) Fix
	RunAsSecurityInterceptor
In-Reply-To: <519744.1184331123674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26315819.1187972420504.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kabir Khan closed JBAS-4546.
----------------------------

    Resolution: Done

> Fix RunAsSecurityInterceptor
> ----------------------------
>
>                 Key: JBAS-4546
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4546
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: AOP
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: JBossAS-4.2.2.GA
>
>
> Add this fix once branch is no longer frozen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 12:45:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 12:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-450) AOP/MC Proxies do not
 include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18984491.1187973918236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-450?page=all ]

Kabir Khan closed JBAOP-450.
----------------------------

    Resolution: Done

Latest javassist snapshot should fix this issue. Contains fix which will be in 3.6.0.CR2

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.beta
>
>         Attachments: test.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 lists.jboss.org  Fri Aug 24 13:28:19 2007
From: jira-events at lists.jboss.org (Arch (JIRA))
Date: Fri, 24 Aug 2007 13:28:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-691) Decision class does
 not allow setting of Decision Delegation
In-Reply-To: <31453146.1152625331489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10969158.1187976499303.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-691?page=comments#action_12373733 ] 
            
Arch commented on JBPM-691:
---------------------------

The org.jbpm.graph.def.Action class already has a method setActionDelegation() to permit the ActionHandler to be set programatically, so it seems reasonable to add a similar method to the Decision class as well.  Instead of hardcoding class names in the XML, I create an XML template of the workflow and programatically inject the ActionHandlers, DecisionHandlers, etc. prior to deployment.

> Decision class does not allow setting of Decision Delegation
> ------------------------------------------------------------
>
>                 Key: JBPM-691
>                 URL: http://jira.jboss.com/jira/browse/JBPM-691
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Windows XP
> MySQL
> WSAD 5.1.2
>            Reporter: Chris OBrien
>         Assigned To: Tom Baeyens
>
> In programmatically creating/manipulating a process definition, one cannot specify a Decision Delegation on a Decision node.
> The Decision class just needs a method like:
>   public void setDecisionDelegation( Delegation del ) {
> 	  this.decisionDelegation = del;
>   }
> I have added this to my install, and it allows me to programmatically change the process definition to define the handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 13:38:19 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 13:38:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-4626) Javassist 3.6.0.CR1
In-Reply-To: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14161400.1187977099780.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kabir Khan reopened JBAS-4626:
------------------------------

             

> Javassist 3.6.0.CR1
> -------------------
>
>                 Key: JBAS-4626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 13:38:20 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 13:38:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4626) Javassist 3.6.0.CR2
In-Reply-To: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20890057.1187977100693.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kabir Khan updated JBAS-4626:
-----------------------------

    Summary: Javassist 3.6.0.CR2  (was: Javassist 3.6.0.CR1)

> Javassist 3.6.0.CR2
> -------------------
>
>                 Key: JBAS-4626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 14:25:28 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 14:25:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1171) Make constructor
 Fqn(List<E> names, boolean safe) public
Message-ID: <4725833.1187979928897.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make constructor Fqn(List<E> names, boolean safe) public
--------------------------------------------------------

                 Key: JBCACHE-1171
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1171
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
            Priority: Minor


This constructor saves the cost of making a defensive copy of the passed in List.  I've got some code that necessarily creates an ArrayList to pass to the Fqn c'tor, but there's no need to copy it; I hold no ref to the List.  Being able to use this c'tor would be a minor optimization.  I don't see any reason not to expose it as public; the javadoc for the constructor is clear about the proper usage.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 14:58:33 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 14:58:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1115) Modifications
 to list
 objects contained within a bean and carried out during the execution of a
 rule are not reflected in the original list i.e. the changes are lost
 between the instance available within the rule  and that of the original
 bean
In-Reply-To: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9343535.1187981913377.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1115?page=comments#action_12373750 ] 
            
Edson Tirelli commented on JBRULES-1115:
----------------------------------------

Ok, I did some debugging and the problem is indeed related to ShadowFacts. Let me first show you my tests:

    public void testShadowProxyOnCollections() throws Exception {
        final PackageBuilder builder = new PackageBuilder();
        builder.addPackageFromDrl( new InputStreamReader( getClass().getResourceAsStream( "test_ShadowProxyOnCollections.drl" ) ) );
        final Package pkg = builder.getPackage();

        final RuleBase ruleBase = getRuleBase();
        ruleBase.addPackage( pkg );
        final WorkingMemory workingMemory = ruleBase.newStatefulSession();

        final List results = new ArrayList();
        workingMemory.setGlobal( "results",
                                 results );

        final Cheesery cheesery = new Cheesery();
        workingMemory.insert( cheesery );

        workingMemory.fireAllRules();

        assertEquals( 1,
                      results.size() );
        assertEquals( 1, 
                      cheesery.getCheeses().size() );
        assertEquals( results.get( 0 ), 
                      cheesery.getCheeses().get( 0 ) );
    }

If we use the following rule, there is no problem, since in the consequence, we unwrap the shadow proxy, and what you get is your original object, where the Cheese is correctly added to the Cheesery object.

package org.drools;
global java.util.List results;

rule "shadow proxy on collections"
	when
		$c : Cheesery()
	then
	    Cheese cheese = new Cheese( "stilton", 10 );
		$c.addCheese( cheese );
		results.add( cheese );
end

Now, if we use "collect" to create a list, like in the following rule, what is added to the list is the object with the shadow proxy wrapper. So, when it is extracted from the list, you are using the shadow proxy and not the original object. There would be no serious problem if you were not using a getXXX() method, because all other non-final methods are delegated... only get methods are shadowed, and so, the getCheeses() method is returning the shadowed collection instead of the original collection:

rule "shadow proxy on collections"
	when
		$list : ArrayList() from collect( Cheesery() )
	then
	    Cheesery $c = (Cheesery) $list.get( 0 );
	    Cheese cheese = new Cheese( "stilton", 10 );
		$c.getCheeses().add( cheese );
		results.add( cheese );
end

So, if instead of getting the collection and add the cheese, a addCheese() method was created into the Cheesery class, if would correctly delegate and add the object to the correct collection:

rule "shadow proxy on collections"
	when
		$c : Cheesery()
	then
	    Cheese cheese = new Cheese( "stilton", 10 );
		$c.addCheese( cheese );
		results.add( cheese );
end

Although, I know this "workaround" is not correct because shadow proxies should not be exposed to custom user code like the consequence. What I'm not sure about is how we can ensure no shadow proxy is exposed if we allow any arbitrary code to be used in semantic code blocks like consequence and accumulate actions... 

Probably we will need to catch known declarations like collect declarations and pre-process them in the consequence, extracting shadow proxies, to avoid such behavior?


> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1115
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: HP-UX  java version "1.5.0.05"
>            Reporter: Anthony Dawson
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> During the execution of the rules when I modify a list my changes are not reflected in my bean. 
> Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.
> Details of this problem are described in the forum messages.
> http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 15:00:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 15:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7784622.1187982018368.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12373751 ] 
            
Edson Tirelli commented on JBRULES-1060:
----------------------------------------

Can we close this issue? Is a OOME you are getting?


> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Fri Aug 24 15:00:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 15:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27815105.1187982018559.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1060:
-----------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Fri Aug 24 15:08:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 15:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4627) Move to JGroups 2.5
Message-ID: <11378851.1187982498232.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move to JGroups 2.5
-------------------

                 Key: JBAS-4627
                 URL: http://jira.jboss.com/jira/browse/JBAS-4627
             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-5.0.0.Beta3


JGroups 2.5.0.GA is out.  AS 5 must use this release or later.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 15:10:21 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 15:10:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4628) Update multiplexer
 protocol stack configs for 2.5
Message-ID: <16779250.1187982621551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update multiplexer protocol stack configs for 2.5
-------------------------------------------------

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


Configure concurrent tack; get rid of deprecated properties, 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 lists.jboss.org  Fri Aug 24 16:04:35 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:04:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-408) Figure out a way
 to use alternate pom files in modules.
Message-ID: <1559246.1187985875287.JavaMail.jira@cloud.prod.atl2.jboss.com>

Figure out a way to use alternate pom files in modules.
-------------------------------------------------------

                 Key: JBBUILD-408
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-408
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Currently the jdk14 builds have to be done as separate modules, because maven is not able to use alternate files (pom-jdk14.xml) in modules.
This issue has been created to address this in maven: http://jira.codehaus.org/browse/MNG-3150
Until this issue is resolved, maybe an ant script can be created to build the modules as an aggregate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 16:04:35 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:04:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-408) Figure out a way
 to use alternate pom files in modules.
In-Reply-To: <1559246.1187985875287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19096071.1187985875417.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-408?page=all ]

Paul Gier reassigned JBBUILD-408:
---------------------------------

    Assignee: Paul Gier

> Figure out a way to use alternate pom files in modules.
> -------------------------------------------------------
>
>                 Key: JBBUILD-408
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-408
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Currently the jdk14 builds have to be done as separate modules, because maven is not able to use alternate files (pom-jdk14.xml) in modules.
> This issue has been created to address this in maven: http://jira.codehaus.org/browse/MNG-3150
> Until this issue is resolved, maybe an ant script can be created to build the modules as an aggregate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 16:10:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-409) Fix microcontainer
	jdk14 tests.
Message-ID: <12323051.1187986218403.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix microcontainer jdk14 tests.
-------------------------------

                 Key: JBBUILD-409
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-409
             Project: JBoss Build System
          Issue Type: Task
          Components: JBossRetro, Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Many of the retro build tests for microcontainer are failing.  These are mostly caused by missing features of jboss-retro.  Once the relevant retro issues have been resolved, the tests should be checked again to find remaining 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 lists.jboss.org  Fri Aug 24 16:10:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1039) Optimized
 replication of entities and extended persistence context in SFSBs
Message-ID: <29571265.1187986218521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimized replication of entities and extended persistence context in SFSBs
---------------------------------------------------------------------------

                 Key: EJBTHREE-1039
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1039
             Project: EJB 3.0
          Issue Type: Feature Request
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry


Optimize replication of clustered SFSBs that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held by the SFSB and those held by the replicated EntityManager.

Currently object identity is maintained by serializing the SFSB and the related EntityManager in one operation. The entire EM is serialized, including entities that have been flushed to the db.  This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.

Intent is to:
1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
2) When writing the fields in an SFSB, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
5) SFSBs should be lazy-deserialized (i.e. only deserialize if needed to handle failover).  This is the way SFSBs clustering already works.  This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.

Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer".  If registered, implementation of many of the steps above would be delegated.  JBoss Seam would intend to register an 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 lists.jboss.org  Fri Aug 24 16:16:29 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-410) Set up retro
 jdk1.4 build and test of microcontainer on hudson.
Message-ID: <17193616.1187986589124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Set up retro jdk1.4 build and test of microcontainer on hudson.
---------------------------------------------------------------

                 Key: JBBUILD-410
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-410
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


A retro build of microcontainer should be set up on hudson so that we can see which tests are failing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 16:18:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4629) Optimized
 replication of entities
 and extended persistence context in HttpSessions
Message-ID: <2279651.1187986698489.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimized replication of entities and extended persistence context in HttpSessions
----------------------------------------------------------------------------------

                 Key: JBAS-4629
                 URL: http://jira.jboss.com/jira/browse/JBAS-4629
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry


Optimize replication of clustered web sessions that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held as a session attribute and those held by the replicated EntityManager.

Currently object identity is maintained by serializing the entire session as one operation (and thus only works reliably if SESSION granularity is used). The entire EM is serialized, including entities that have been flushed to the db. This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.

Intent is to:
1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
2) When writing the attributes in the session, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
5) Sessions should be lazy-deserialized (i.e. only deserialize if needed to handle failover). This is the way web session clustering already works. This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.

Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer". If registered, implementation of many of the steps above would be delegated. JBoss Seam would intend to register an 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 lists.jboss.org  Fri Aug 24 16:20:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1039) Optimized
 replication of entities and extended persistence context in SFSBs
In-Reply-To: <29571265.1187986218521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12507279.1187986818225.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1039?page=comments#action_12373765 ] 
            
Brian Stansberry commented on EJBTHREE-1039:
--------------------------------------------

EJBTHREE-1039 and JBAS-4629 involve the same concepts applied to SFSBs and HttpSessions, respectively.

> Optimized replication of entities and extended persistence context in SFSBs
> ---------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1039
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1039
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> Optimize replication of clustered SFSBs that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held by the SFSB and those held by the replicated EntityManager.
> Currently object identity is maintained by serializing the SFSB and the related EntityManager in one operation. The entire EM is serialized, including entities that have been flushed to the db.  This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.
> Intent is to:
> 1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
> 1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
> 2) When writing the fields in an SFSB, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
> 3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
> 4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
> 5) SFSBs should be lazy-deserialized (i.e. only deserialize if needed to handle failover).  This is the way SFSBs clustering already works.  This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.
> Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer".  If registered, implementation of many of the steps above would be delegated.  JBoss Seam would intend to register an 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 lists.jboss.org  Fri Aug 24 16:29:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4630) Coordinate optimized
 entity/XPC replication across web and ejb3 tiers
Message-ID: <18148510.1187987358480.JavaMail.jira@cloud.prod.atl2.jboss.com>

Coordinate optimized entity/XPC replication across web and ejb3 tiers
---------------------------------------------------------------------

                 Key: JBAS-4630
                 URL: http://jira.jboss.com/jira/browse/JBAS-4630
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering, EJB3, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry


See EJBTHREE-1039 and JBAS-4629 for background.

For use cases that involve requests that store entities and XPCs in both the web and ejb3 tiers, need to ensure that the process is properly handled.

At minimum, need to ensure that the XPC is always deserialized before any managed entities, no matter what the access pattern is.

It would also be nice to avoid duplicate serialization of the XPC.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 17:36:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-406) Create retro build
	for aop
In-Reply-To: <1127269.1187729719337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6188043.1187991378633.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-406?page=all ]

Paul Gier closed JBBUILD-406.
-----------------------------

    Resolution: Done

AOP now has a basic retro build in place.
The rest will be completed when the general aop mavenization is complete.

> Create retro build for aop
> --------------------------
>
>                 Key: JBBUILD-406
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-406
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> AOP needs a retro 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 lists.jboss.org  Fri Aug 24 17:40:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-93) Add JBossRetro
 builds for Microcontainer projects
Message-ID: <15705701.1187991618365.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Paul Gier closed JBMICROCONT-93.
--------------------------------

    Resolution: Done

The basic retro builds and tests are now in place.  I created new issues for setting up hudson builds, and for resolving the remaining issues with the tests.
Due to a limitation in maven, the retro modules have to be built individually instead of as an aggregated project.  I will try to get this issue resolved in an upcoming release of maven.

> Add JBossRetro builds for Microcontainer projects
> -------------------------------------------------
>
>                 Key: JBMICROCONT-93
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93
>             Project: JBoss MicroContainer
>          Issue Type: Sub-task
>          Components: General
>            Reporter: Adrian Brock
>         Assigned To: Paul Gier
>             Fix For: JBossMC-2.0.0.CR1
>
>
> Make JBossRetro builds for the microcontainer projects
> such that they can use JDK5 features.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 17:43:31 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:43:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-407) Migrate
 microcontainer docbook gen to jdocbook plugin
In-Reply-To: <26415361.1187899278199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10547195.1187991811918.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-407?page=all ]

Paul Gier reassigned JBBUILD-407:
---------------------------------

    Assignee: Paul Gier

> Migrate microcontainer docbook gen to jdocbook plugin
> -----------------------------------------------------
>
>                 Key: JBBUILD-407
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-407
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Microcontainer should use the maven-jdocbook-plugin for it's doc generation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 17:57:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-203) Analyze
 microcontainer dependencies
Message-ID: <19082098.1187992638420.JavaMail.jira@cloud.prod.atl2.jboss.com>

Analyze microcontainer dependencies
-----------------------------------

                 Key: JBMICROCONT-203
                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-203
             Project: JBoss MicroContainer
          Issue Type: Task
          Components: General
            Reporter: Paul Gier
         Assigned To: Paul Gier
             Fix For: JBossMC-2.0.0.CR1


Using the mvn dependency plugin "mvn dependency:analyze", I noticed that several of the microcontainer modules are using transitive dependencies directly and/or are listing dependencies that aren't used.  This dependency tool should be used to clean up these dependencies a bit to make it more clear which ones are required for compilation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:10:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 18:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1121) Operator field
 and the fact's
 variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26950896.1187993418624.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1121:
----------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms, Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:10:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 18:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1114) Rule
 compilation not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6605441.1187993418926.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1114?page=comments#action_12373780 ] 
            
Edson Tirelli commented on JBRULES-1114:
----------------------------------------

Ok, we found the error in the template engine we are using for code generation. Working on the fix.

> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:10:19 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Fri, 24 Aug 2007 18:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29897339.1187993419090.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373781 ] 
            
Michael Neale commented on JBRULES-1121:
----------------------------------------

in the "then" part - if you put an "=" at the start (a bit like in excel) you can do a calculation (it won't be a text field). 

Is that what you want? 

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms, Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:25:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1032) inconsistent
 results for
 CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
In-Reply-To: <32360816.1187381960564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17435867.1187994318254.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste closed EJBTHREE-1032.
-------------------------------------

    Fix Version/s: AS 4.2.2.GA
                   Branch_4_2
       Resolution: Done

> inconsistent results for CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
> -----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1032
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1032
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1, AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.GA, Branch_4_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 lists.jboss.org  Fri Aug 24 18:37:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1040) add flag to
 improve
 deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
Message-ID: <18074307.1187995038327.JavaMail.jira@cloud.prod.atl2.jboss.com>

add flag to improve deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
--------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1040
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1040
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: AS 4.2.1.GA
            Reporter: William DeCoste
         Assigned To: William DeCoste
            Priority: Minor


Currently all jar/ejb3 files are scanned for the existence of annotated classes. This can cause slow deployment times. Create a switch with flag for only deploying jar/ejb3 files with either/or a ejb-jar.xml or jboss.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 lists.jboss.org  Fri Aug 24 18:39:22 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:39:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22610176.1187995162287.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12373785 ] 
            
William DeCoste commented on EJBTHREE-1025:
-------------------------------------------

The above construct should throw an EJBException at deployment time.

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:39:22 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:39:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17028678.1187995162484.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste updated EJBTHREE-1025:
--------------------------------------

    Comment: was deleted

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:41:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18953643.1187995278571.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste updated EJBTHREE-1025:
--------------------------------------

    Description: 
The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

There is a test for this construct in Branch_4_2.

  was:
The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}


> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}
> There is a test for this construct in Branch_4_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 lists.jboss.org  Fri Aug 24 19:04:18 2007
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Fri, 24 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4611) HTTP Session Repl
 Cache configured with CacheLoader can cause slow AS shutdowns
In-Reply-To: <26411619.1187251081159.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21936881.1187996658288.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4611?page=comments#action_12373789 ] 
            
Jimmy Wilson commented on JBAS-4611:
------------------------------------

Switching the invocation order made no difference as getChildrenNames still went remote.

> HTTP Session Repl Cache configured with CacheLoader can cause slow AS shutdowns
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-4611
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4611
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering, JBoss Cache
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> When AS stops, the sessions for that web app are evicted from memory, 
> which means removing from the memory locally. We still need the sessions
>  in other nodes, for example if we're bringing a node down for maintenance 
> in which case, we don't want to remove sessions of the cluster completely. 
> We want users to failover to another node and continue as normal.
> The code handling this evictions first removes any data in these sessions and
>  then tries to check whether this HTTP session has any children nodes in the
>  cache so that it can do a complete clearout of the subtree:
> JBossCacheWrapper:
>    void evictSubtree(Fqn fqn)
>    {
>       Exception ex = null;
>       for (int i = 0; i < RETRY; i++)
>       {
>          try
>          {
>             // Evict the node itself first, since if it stores a Pojo
>             // that will do everything
>             proxy_.evict(fqn);
>             // next do a depth first removal; this ensure all nodes
>             // are removed, not just their data map
>             Set children = proxy_.getChildrenNames(fqn);
> ...
> If no cache loaders were used, this would be fine, it wouldn't find any 
> children in memory and would return quickly. A true local call. 
> However, for a customer who's using a ClusteredCacheLoader to get around 
> some state transfer issues, when AS discovers that this session does 
> not contain any children nodes, it goes remote to find them because 
> it didn't find them locally (won't find them remotely either):
> CacheLoaderInterceptor:
>    private boolean mustLoad(DataNode n, Object key)
>    {
>       return n == null ||
>               (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key)));
>    }
> As the node has been emptied, CLI (CacheLoaderInterceptor) thinks it 
> needs to go remote. Same thing would happen with Pojo too (as the 
> entire node is emptied). This is an unnecessary trip which is delaying 
> the local eviction of sessions.
> This would happen regardless of the CacheLoader used.
> Two possible solutions come to my mind:
> - easy one: call getChildrenNames() before evict and cache in a local variable the 
> children Set. getChildrenNames() would land locally cos the fqn exists yet.
> - complex one: do a getChildrenNames(Option) passing an option indicating that 
> if the lookup fails locally, don't bother going remote.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 19:26:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 19:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18256668.1187997978905.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer reassigned JBRULES-1106:
---------------------------------------

    Assignee: Fernando Meyer  (was: Michael Neale)

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 19:31:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 19:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1106) Copied rules using
 a guided DSL
 in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25426170.1187998278295.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer closed JBRULES-1106.
-----------------------------------

    Resolution: Done

missing copy step was added to handle with brxml assets 

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 19:53:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Aug 2007 19:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
Message-ID: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>

DistributedTopicTest::testClusteredTopicDurablePersistent fails
---------------------------------------------------------------

                 Key: JBMESSAGING-1059
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR1
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
            Priority: Blocker
             Fix For: 1.4.0.CR2


Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...

There is an patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Fri Aug 24 19:55:46 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Aug 2007 19:55:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
In-Reply-To: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5360919.1187999746598.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBMESSAGING-1059:
-----------------------------------------

    Attachment: jbmessaging-1059.patch

> DistributedTopicTest::testClusteredTopicDurablePersistent fails
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1059
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>         Attachments: jbmessaging-1059.patch
>
>
> Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...
> There is an patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Fri Aug 24 19:55:46 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Aug 2007 19:55:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
In-Reply-To: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16797082.1187999746755.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBMESSAGING-1059:
-----------------------------------------

    Description: 
Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...

There is a patch attached for a probable fix on the test.. but I want to investigate this before committing the patch.

  was:
Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...

There is an patch attached for a probable fix on the test.. but I want to investigate this before committing the patch.


> DistributedTopicTest::testClusteredTopicDurablePersistent fails
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1059
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>         Attachments: jbmessaging-1059.patch
>
>
> Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...
> There is a patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Fri Aug 24 20:31:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1123) Custom
 Consequence Exception handlers
Message-ID: <1209026.1188001878202.JavaMail.jira@cloud.prod.atl2.jboss.com>

Custom Consequence Exception handlers
-------------------------------------

                 Key: JBRULES-1123
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1123
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 4.0.1


RuleBaseConfiguration should allow the user to specify a custom handler for consequence exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:33:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1123) Custom
 Consequence Exception handlers
In-Reply-To: <1209026.1188001878202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16456013.1188001998208.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

users can now use the property "drools.consequenceExceptionHandler" or the RuleBaseconfiguration.setConsequenceExceptionHandler to specify a custom user defined handler for consequence exceptions.

> Custom Consequence Exception handlers
> -------------------------------------
>
>                 Key: JBRULES-1123
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1123
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> RuleBaseConfiguration should allow the user to specify a custom handler for consequence exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:35:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1123) Custom Consequence
 Exception handlers
In-Reply-To: <1209026.1188001878202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29816719.1188002118233.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1123.
---------------------------------

    Resolution: Done

> Custom Consequence Exception handlers
> -------------------------------------
>
>                 Key: JBRULES-1123
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1123
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> RuleBaseConfiguration should allow the user to specify a custom handler for consequence exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:54:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-851) Provide RuleFlow
 editing capabilities within JBRMS
In-Reply-To: <10955939.1179153237844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33358412.1188003258390.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I believe you can already handle ruleflow as assets in the BRMS.

> Provide RuleFlow editing capabilities within JBRMS
> --------------------------------------------------
>
>                 Key: JBRULES-851
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-851
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Anstis
>         Assigned To: Mark Proctor
>
> Ruleflow should be available in the JBRMS (apologies is this JIRA should have been raised against JBRMS).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:56:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1122) Eclipse-JDT
 compiler jar
 (core-3.2.0.666.jar) for drools creates problems/conflicts with the
 existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
In-Reply-To: <527189.1187948822233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8734018.1188003378277.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1122.
---------------------------------

    Resolution: Rejected

The is already covered here http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesTomcat

> Eclipse-JDT compiler jar (core-3.2.0.666.jar) for drools creates problems/conflicts with the existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1122
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1122
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.6,  4.0.0.GA
>         Environment: Windows XP / JDK 1.5.0_06-b05
>            Reporter: Suman Ghosh
>         Assigned To: Mark Proctor
>
> I'm running a service using JBoss, which uses Drools for its various rule-based components. The propblem arises like this -  when I use the JDTcompiler in Drools, tomcat crashes with the following stacktrace (when used to access JSPs - such as the JBoss JMX console)....
> ----------------------------------------------------START-------------------------------------------------------------------
> type Exception report
> message
> description The server encountered an internal error () that prevented it from fulfilling this request.
> exception
> javax.servlet.ServletException: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
> 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:272)
> 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> root cause
> java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
> 	org.apache.jasper.compiler.JDTCompiler$2.acceptResult(JDTCompiler.java:345)
> 	org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417)
> 	org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:404)
> 	org.apache.jasper.compiler.Compiler.compile(Compiler.java:297)
> 	org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
> 	org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
> 	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
> 	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303)
> 	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
> 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
> 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
> ---------------------------------------------------END--------------------------------------------------------------------
> Seems that the class CompilationResult from the new JDT distribution has a different signature for the getProblems() method - but tomcat expects the earlier one only.
> For my application, I *have* to use the JDT compiler for my rule base, and on the other hand, I require the jboss jmx-console, for service monitoring and method invokations :(
> Please suggest a solution!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:58:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-851) Provide RuleFlow
 editing capabilities within JBRMS
In-Reply-To: <10955939.1179153237844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20038791.1188003498272.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

or where you talking about actually editing ruleflows in the BRMS? Not sure how we would do that, dhtml doesn't handle graphs well. We would have to look into building an SVG system, or figure  out how to webstate an RCP version of the Eclipse IDE.

> Provide RuleFlow editing capabilities within JBRMS
> --------------------------------------------------
>
>                 Key: JBRULES-851
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-851
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Anstis
>         Assigned To: Mark Proctor
>
> Ruleflow should be available in the JBRMS (apologies is this JIRA should have been raised against JBRMS).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 21:05:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 21:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-851) Provide RuleFlow
 editing capabilities within JBRMS
In-Reply-To: <10955939.1179153237844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12344179.1188003918351.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Fernando Meyer reassigned JBRULES-851:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> Provide RuleFlow editing capabilities within JBRMS
> --------------------------------------------------
>
>                 Key: JBRULES-851
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-851
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Anstis
>         Assigned To: Fernando Meyer
>
> Ruleflow should be available in the JBRMS (apologies is this JIRA should have been raised against JBRMS).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 21:55:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 21:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1124) Code completion
 does not work for 'with' blocks
Message-ID: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>

Code completion does not work for 'with' blocks
-----------------------------------------------

                 Key: JBRULES-1124
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 21:57:30 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 21:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13259892.1188007050763.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1124:
----------------------------------

    Attachment: withCodeCompletion.JPG

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 22:11:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1125) Java Step over is
	broken
Message-ID: <26835535.1188007878253.JavaMail.jira@cloud.prod.atl2.jboss.com>

Java Step over is broken
------------------------

                 Key: JBRULES-1125
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1125
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


Java Step Over is broken. I put in a break point and I can't step through the 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 lists.jboss.org  Fri Aug 24 22:15:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1126) Step over in MVEL
	is broken
Message-ID: <33412742.1188008118280.JavaMail.jira@cloud.prod.atl2.jboss.com>

Step over in MVEL is broken
---------------------------

                 Key: JBRULES-1126
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1126
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1


cbrock says that step and step-over have been mapped incorrectly. Thus step-over does not work with MVEL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 22:19:24 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1127) External vars do
 not appear if you hve a break point on the first line
Message-ID: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>

External vars do not appear if you hve a break point on the first line
----------------------------------------------------------------------

                 Key: JBRULES-1127
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1
         Attachments: debugvars1.jpg, debugvars2.jpg

if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Fri Aug 24 22:19:25 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:19:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1127) External vars do
 not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9178690.1188008365088.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1127:
----------------------------------

    Attachment: debugvars1.jpg
                debugvars2.jpg

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 00:34:18 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Sat, 25 Aug 2007 00:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
In-Reply-To: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16432107.1188016458492.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Scott M Stark resolved JBAS-4593.
---------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                   JBossAS-4.2.2.GA
       Resolution: Done

Added a org.jboss.mx.loading.UnifiedLoaderRepository.notifyMode system property that controls how whether a jmx notification is sent, if done, whether the class loader is wrapped in a WeakReference. It should be set to one of 0, 1 or 2:
   // Send notification with the ClassLoader as the user data
   private static int LEGACY_MODE = 0;
   // Send notification with the ClassLoader as the user data wrapped in a WeakReference
   private static int WEAK_REFERENCE_MODE = 1;
   // Don't send any notifications
   private static int NO_NOTIFICATION_MODE = 2;

The default is the LEGACY_MODE.


> Leak in org/jboss/mx/loading/UnifiedClassLoader3
> ------------------------------------------------
>
>                 Key: JBAS-4593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Scott M Stark
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> [description pasted from support case]
> After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:
> found a path to the target: 26093 (depth: 5)
> 0 0 Heap root
> 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
> 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
> 160611 0 Instance: [Ljava/lang/Object;
> 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
> 217357 0 Instance: Ljavax/management/Notification;
> 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;
> So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.
> Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 07:36:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Sat, 25 Aug 2007 07:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-691) Decision class does
 not allow setting of Decision Delegation
In-Reply-To: <31453146.1152625331489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4181973.1188041778297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-691?page=all ]

Ronald van Kuijk updated JBPM-691:
----------------------------------

    Priority: Minor  (was: Major)

Why not just write a patch for the source instead of this 'workaround'? That patch can be included then in jbpm (if the developers agree)

> Decision class does not allow setting of Decision Delegation
> ------------------------------------------------------------
>
>                 Key: JBPM-691
>                 URL: http://jira.jboss.com/jira/browse/JBPM-691
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Windows XP
> MySQL
> WSAD 5.1.2
>            Reporter: Chris OBrien
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> In programmatically creating/manipulating a process definition, one cannot specify a Decision Delegation on a Decision node.
> The Decision class just needs a method like:
>   public void setDecisionDelegation( Delegation del ) {
> 	  this.decisionDelegation = del;
>   }
> I have added this to my install, and it allows me to programmatically change the process definition to define the handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:08:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 08:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1126) Step over in
	MVEL is broken
In-Reply-To: <33412742.1188008118280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24268257.1188043698293.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

When placing a breakpoint on the first line of the hello world example. It would stop ok, I would press step-over and it would show this error:
org.mvel.PropertyAccessException: unable to resolve property: ;
	at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:287)
	at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109)
	at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:182)
	at org.mvel.MVELRuntime.execute(MVELRuntime.java:85)
	at org.mvel.MVEL.executeDebugger(MVEL.java:344)
	at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:39)

cbrock says this is because mvel has both step and step-over and you really want to use mvel step, or something like that.

> Step over in MVEL is broken
> ---------------------------
>
>                 Key: JBRULES-1126
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1126
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> cbrock says that step and step-over have been mapped incorrectly. Thus step-over does not work with MVEL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:31:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1128) Xstream should be
 optional for drools-core and it should use the non-legacy groupId
Message-ID: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>

Xstream should be optional for drools-core and it should use the non-legacy groupId 
------------------------------------------------------------------------------------

                 Key: JBRULES-1128
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
             Project: JBoss Rules
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
             Fix For: FUTURE



        <!-- Xstream -->
        <dependency>
            <groupId>com.thoughtworks.xstream</groupId>
            <artifactId>xstream</artifactId>
            <version>1.2.2</version>
        </dependency>



        <!-- Xstream -->
        <dependency>
            <groupId>com.thoughtworks.xstream</groupId>
            <artifactId>xstream</artifactId>
            <optional>true</optional><!-- Only needed for auditing -->
        </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:35:22 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:35:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1128) Xstream should
 be optional for drools-core and it should use the non-legacy groupId
In-Reply-To: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28893281.1188045322248.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1128?page=comments#action_12373826 ] 
            
Geoffrey De Smet commented on JBRULES-1128:
-------------------------------------------

Being non optional and having the non-legacy groupId it caused some classpath havoc in taseree.

> Xstream should be optional for drools-core and it should use the non-legacy groupId 
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1128
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
>             Project: JBoss Rules
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>             Fix For: FUTURE
>
>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <version>1.2.2</version>
>         </dependency>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <optional>true</optional><!-- Only needed for auditing -->
>         </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:49:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27811770.1188046158660.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet reassigned JBRULES-992:
----------------------------------------

    Assignee: Geoffrey De Smet  (was: Mark Proctor)

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Sat Aug 25 08:55:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15568019.1188046518254.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-992?page=comments#action_12373827 ] 
            
Geoffrey De Smet commented on JBRULES-992:
------------------------------------------

 <conan> ge0ffrey: just add the information to the dependencies README docs.


> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Sat Aug 25 10:33:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 25 Aug 2007 10:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1115) Modifications to
 list objects
 contained within a bean and carried out during the execution of a rule are
 not reflected in the original list i.e. the changes are lost  between the
 instance available within the rule  and that of the original bean
In-Reply-To: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27396613.1188052398735.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-1115.
------------------------------------

    Resolution: Done

As discussed, I added some controls to unwrap shadow proxies in the case of collection objects created by the collect CE.

Integration test added.

Thank you for reporting and providing test case. Please let us know if you find any other related problem.

Fix will be included in 4.0.1 release.


> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1115
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: HP-UX  java version "1.5.0.05"
>            Reporter: Anthony Dawson
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> During the execution of the rules when I modify a list my changes are not reflected in my bean. 
> Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.
> Details of this problem are described in the forum messages.
> http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 11:15:18 2007
From: jira-events at lists.jboss.org (Alexandre Russel (JIRA))
Date: Sat, 25 Aug 2007 11:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1141) Redesign
 evictions for greater flexibility
In-Reply-To: <1163240.1184750387057.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10245574.1188054918250.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1141?page=comments#action_12373833 ] 
            
Alexandre Russel commented on JBCACHE-1141:
-------------------------------------------

I hadn't seen that bug sending a patch for the #11. I believe my patch "part answer" this bug as well.
http://jira.jboss.com/jira/browse/JBCACHE-11
alex

> Redesign evictions for greater flexibility
> ------------------------------------------
>
>                 Key: JBCACHE-1141
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1141
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 3.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 lists.jboss.org  Sat Aug 25 12:04:22 2007
From: jira-events at lists.jboss.org (Wolfgang Hollweck (JIRA))
Date: Sat, 25 Aug 2007 12:04:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1048) Userguide Section
 18.1.1 is
 missleading when describing ant task for deploment of par archive
Message-ID: <26836191.1188057862767.JavaMail.jira@cloud.prod.atl2.jboss.com>

Userguide Section 18.1.1 is missleading when describing ant task for deploment of par archive
---------------------------------------------------------------------------------------------

                 Key: JBPM-1048
                 URL: http://jira.jboss.com/jira/browse/JBPM-1048
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Documentation
    Affects Versions: jBPM jPDL 3.2, jBPM 3.1.4
            Reporter: Wolfgang Hollweck
         Assigned To: Tom Baeyens
            Priority: Minor
             Fix For: jBPM jPDL 3.2, jBPM 3.1.4


Section 18.1.1 in Userguide declares
classname="org.jbpm.ant.DeployParTask"
which does not exist.

It must be called
classname "org.jbpm.ant.DeployProcessTask"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:12:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1129) import does not
 work with code competion
Message-ID: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>

import does not work with code competion
----------------------------------------

                 Key: JBRULES-1129
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
            Priority: Blocker
             Fix For: 4.0.1


imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:14:29 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9275562.1188058469561.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

this is worse than I thought. I added a rule and the code completion works, sort of by overwritting the rule.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:16:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32675310.1188058578350.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1129:
----------------------------------

    Attachment: screenshot-1.jpg

here it correctly shows the matching imports.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:18:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33527341.1188058698327.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1129:
----------------------------------

    Attachment: screenshot-2.jpg

This is the screenshot after I select the import, see how it over-writes the rule statement.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:24:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1130) Code completion
 does not work for two char operator symbols
Message-ID: <22006280.1188059058281.JavaMail.jira@cloud.prod.atl2.jboss.com>

Code completion does not work for two char operator symbols
-----------------------------------------------------------

                 Key: JBRULES-1130
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1130
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


When typing the first char of an operator, it does not show you the correct matches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:26:23 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1130) Code completion
 does not work for two char operator symbols
In-Reply-To: <22006280.1188059058281.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3766489.1188059184007.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1130:
----------------------------------

    Attachment: screenshot-1.jpg

Notice here I have selected a single = operator, it should show ==, but shows something totally none relevant.

> Code completion does not work for two char operator symbols
> -----------------------------------------------------------
>
>                 Key: JBRULES-1130
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1130
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> When typing the first char of an operator, it does not show you the correct matches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:50:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1131) Errors not
 including line numbers
Message-ID: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>

Errors not including line numbers
---------------------------------

                 Key: JBRULES-1131
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder, Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sat Aug 25 12:52:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24842455.1188060738315.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1131:
----------------------------------

    Attachment: screenshot-1.jpg

see the from ShoppingCart() is obviously wrong. Its producing an Error, but there are no line numbers and it's not reflected in the outline view.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sat Aug 25 12:54:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1132) No code
 completion for 'from' expression statements
Message-ID: <28151937.1188060858274.JavaMail.jira@cloud.prod.atl2.jboss.com>

No code completion for 'from' expression statements
---------------------------------------------------

                 Key: JBRULES-1132
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1132
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


If I'm buliding a 'from' statement that is something like from $s.getItems() there is no code completion on that expression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:35:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 15:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1128) Xstream should
 be optional for drools-core and it should use the non-legacy groupId
In-Reply-To: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17742645.1188070518245.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1128?page=comments#action_12373845 ] 
            
Geoffrey De Smet commented on JBRULES-1128:
-------------------------------------------

on irc they said it's ok to upgrade it to the latest version too - which is good for drools-solver which needs at least 1.2.2

> Xstream should be optional for drools-core and it should use the non-legacy groupId 
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1128
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
>             Project: JBoss Rules
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>             Fix For: FUTURE
>
>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <version>1.2.2</version>
>         </dependency>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <optional>true</optional><!-- Only needed for auditing -->
>         </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:43:31 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 15:43:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1128) Xstream should
 be optional for drools-core and it should use the non-legacy groupId
In-Reply-To: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28747245.1188071011788.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet resolved JBRULES-1128.
---------------------------------------

    Fix Version/s: 4.0.1
                       (was: FUTURE)
       Resolution: Done

done

> Xstream should be optional for drools-core and it should use the non-legacy groupId 
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1128
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
>             Project: JBoss Rules
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <version>1.2.2</version>
>         </dependency>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <optional>true</optional><!-- Only needed for auditing -->
>         </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:51:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Sat, 25 Aug 2007 15:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1239479.1188071478473.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1124?page=comments#action_12373848 ] 
            
Philippe Ombredanne commented on JBRULES-1124:
----------------------------------------------

Could you give a hints? What is a with block?
Where are you trying to complete? after the , and before the closing } ?
What would you expect for completions there?

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:51:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Sat, 25 Aug 2007 15:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5968989.1188071478720.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=comments#action_12373849 ] 
            
Philippe Ombredanne commented on JBRULES-1127:
----------------------------------------------

Is this really a major issue?

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 15:51:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 15:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1133) Janino and
 eclipse compiler might need to be optional for 4.1
Message-ID: <3544593.1188071478914.JavaMail.jira@cloud.prod.atl2.jboss.com>

Janino and eclipse compiler might need to be optional for 4.1
-------------------------------------------------------------

                 Key: JBRULES-1133
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1133
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
            Priority: Minor
             Fix For: FUTURE


I didn't want to make this change for 4.0.x as it would require our users to put a direct dependency on either janino or eclipse-compiler.

Drools-compiler needs one of both.
Currently users get bloated with a transitive dependency on both.
Making them optional would force them to make a dependency on one of the themselves... which makes the "hello world" program harder.
As it would also force jbrms's etc tests to choose one.

Why shouldn't do this before 4.1, if we even want to do this.

What do you think?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 16:01:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 16:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30350384.1188072078447.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Geoffrey De Smet resolved JBRULES-992.
--------------------------------------

    Resolution: Partially Completed

I didn't make janino and eclipse-compiler optional - see JBRULES-1133 as that should be done for a minor (non hotfix) release if it needs to be done in the first case.

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Sat Aug 25 16:18:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1125) Java Step over is
	broken
In-Reply-To: <26835535.1188007878253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22559598.1188073098473.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ahti Kitsik closed JBRULES-1125.
--------------------------------

    Resolution: Done

change in mvel Debugger interface caused this. Having STEP=STEP_OVER introduces unexpected behaviour in debugging logic (now both step conditions are triggered).

> Java Step over is broken
> ------------------------
>
>                 Key: JBRULES-1125
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1125
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>
> Java Step Over is broken. I put in a break point and I can't step through the 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 lists.jboss.org  Sat Aug 25 16:18:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1125) Java Step over
	is broken
In-Reply-To: <26835535.1188007878253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30120703.1188073098670.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1125?page=comments#action_12373854 ] 
            
Ahti Kitsik commented on JBRULES-1125:
--------------------------------------

sry, this comment was about JBRULES-1126

java step over was broken because of mvel debug implementation (wrong stepover stackframe detection mechanism).

> Java Step over is broken
> ------------------------
>
>                 Key: JBRULES-1125
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1125
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>
> Java Step Over is broken. I put in a break point and I can't step through the 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 lists.jboss.org  Sat Aug 25 16:20:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1126) Step over in MVEL
	is broken
In-Reply-To: <33412742.1188008118280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25908622.1188073218343.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ahti Kitsik closed JBRULES-1126.
--------------------------------

    Resolution: Done

change in mvel Debugger interface caused this. Having STEP=STEP_OVER introduces unexpected behaviour in debugging logic (now both step conditions are triggered).

> Step over in MVEL is broken
> ---------------------------
>
>                 Key: JBRULES-1126
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1126
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> cbrock says that step and step-over have been mapped incorrectly. Thus step-over does not work with MVEL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 16:20:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1133) Janino and
 eclipse compiler might need to be optional for 4.1
In-Reply-To: <3544593.1188071478914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21161999.1188073218470.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1133?page=comments#action_12373856 ] 
            
Geoffrey De Smet commented on JBRULES-1133:
-------------------------------------------

[22:18] <conan> yes it would be unwise to change it now
[22:18] <conan> people can still exclude
[22:18] <ge0ffrey> in worst case, they can start doing <exclusions>... as this isn't a clear optional dep I 'd leave it like this for now


> Janino and eclipse compiler might need to be optional for 4.1
> -------------------------------------------------------------
>
>                 Key: JBRULES-1133
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1133
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>             Fix For: FUTURE
>
>
> I didn't want to make this change for 4.0.x as it would require our users to put a direct dependency on either janino or eclipse-compiler.
> Drools-compiler needs one of both.
> Currently users get bloated with a transitive dependency on both.
> Making them optional would force them to make a dependency on one of the themselves... which makes the "hello world" program harder.
> As it would also force jbrms's etc tests to choose one.
> Why shouldn't do this before 4.1, if we even want to do this.
> What do you think?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 16:28:22 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:28:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24171428.1188073702598.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=comments#action_12373857 ] 
            
Ahti Kitsik commented on JBRULES-1127:
--------------------------------------

For the reference, this is used in debugger code:

get the list of vars:
return getFactory().getKnownVariables()

get the value for a given varName:
return getVariableResolver(varName).getValue()

Unfortunately I don't have a control to get global vars registered before first line of mvel code is evaluated.
I think it's possible to make this preparation in mvel code (before line=1 breakpoint would be triggered).

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 20:44:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 20:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31753171.1188089058278.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

mvel has a with block to execute block setters on an object:
with ( object ) { field1 = value1, field2 = expression2 };

We use the macro process on "modify" to change:
modify ( object ) { field1 = value1, field2 = expression2 };

Into this:
@Modify with ( object ) { field1 = value1, field2 = expression2 };

this is the prefered way in Drools and MVEL  to modify facts, as it sets the setters and calls modify in one go.

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 21:04:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 21:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1134) drools variable
 appears twice in context assist
Message-ID: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>

drools variable appears twice in context assist
-----------------------------------------------

                 Key: JBRULES-1134
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1
         Attachments: screenshot-1.jpg

The drools variable appears twice in context compliation, once typed and once as Object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 21:04:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 21:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28439557.1188090258468.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1134:
----------------------------------

    Attachment: screenshot-1.jpg

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 21:48:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 21:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32757081.1188092898299.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=comments#action_12373864 ] 
            
Ahti Kitsik commented on JBRULES-1127:
--------------------------------------

Comment from Mark:
getInputs gets all used external identifiers
then call isResolvable() which lazily creates the resolver
then you can do getVariableResolvers().get(identifier).getValue()

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 22:57:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 22:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27111762.1188097038350.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I think I can fix this my end by updating the MVEL Factory, think I have a clean way of doing this - just debugging it now.

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 23:05:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Aug 2007 23:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1172)
 CacheLoaderInterceptor doesn't
 load data for Node.getKeys() or Node.getData()
Message-ID: <12017577.1188097518214.JavaMail.jira@cloud.prod.atl2.jboss.com>

CacheLoaderInterceptor doesn't load data for Node.getKeys() or Node.getData()
-----------------------------------------------------------------------------

                 Key: JBCACHE-1172
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1172
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 2.0.0.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: 2.1.0.GA


CacheLoaderInterceptor.mustLoad always returns false if there is no data key associated with the MethodCall.  Effect is calls for CacheImpl._getKeys  and _getData don't trigger a load from the cache loader.

Added tests testKeyKeys() and testGetData() to CacheLoaderTestsBase to show the issue.

Solution is to add a boolean 'allKeys' variable to CacheLoaderInterceptor.invoke.  Set it to true if the MethodCall is _getKeys or _getData.  Pass the value through to mustLoad, and if true load the data if Node.isDataLoaded returns 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 lists.jboss.org  Sat Aug 25 23:11:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 23:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1127) External vars do
 not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12654103.1188097878263.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1127.
---------------------------------

    Resolution: Done

yes managed to fix this in the factory, in debug mode it eager creates the external resolvers. The impl is quite clean, so I'm happy with it this way. Found another MVEL bug, where it doesn't find all external inputs, have creating a failing test in MVEL for this.

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 23:19:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Aug 2007 23:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1172)
 CacheLoaderInterceptor doesn't
 load data for Node.getKeys() or Node.getData()
In-Reply-To: <12017577.1188097518214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15336328.1188098358228.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1172?page=all ]

Brian Stansberry closed JBCACHE-1172.
-------------------------------------

    Resolution: Done

> CacheLoaderInterceptor doesn't load data for Node.getKeys() or Node.getData()
> -----------------------------------------------------------------------------
>
>                 Key: JBCACHE-1172
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1172
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 2.0.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.1.0.GA
>
>
> CacheLoaderInterceptor.mustLoad always returns false if there is no data key associated with the MethodCall.  Effect is calls for CacheImpl._getKeys  and _getData don't trigger a load from the cache loader.
> Added tests testKeyKeys() and testGetData() to CacheLoaderTestsBase to show the issue.
> Solution is to add a boolean 'allKeys' variable to CacheLoaderInterceptor.invoke.  Set it to true if the MethodCall is _getKeys or _getData.  Pass the value through to mustLoad, and if true load the data if Node.isDataLoaded returns 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 lists.jboss.org  Sun Aug 26 00:32:30 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 26 Aug 2007 00:32:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22218318.1188102750238.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

This may be an MVEL issue, I'm debugging this one myself at the moment,to try and pin point where its going wrong.

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 01:34:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sun, 26 Aug 2007 01:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
In-Reply-To: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4309432.1188106458239.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1059.
----------------------------------------

    Resolution: Done

> DistributedTopicTest::testClusteredTopicDurablePersistent fails
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1059
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>         Attachments: jbmessaging-1059.patch
>
>
> Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...
> There is a patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Sun Aug 26 08:38:35 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 26 Aug 2007 08:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1135) Move generation
 should be described in a drl
Message-ID: <10304513.1188131915761.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move generation should be described in a drl
--------------------------------------------

                 Key: JBRULES-1135
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1135
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Solver
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
             Fix For: FUTURE


instead of MoveFactory POJO

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 08:55:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Aug 2007 08:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1114) Rule compilation
 not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13791079.1188132918341.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-1114.
------------------------------------

    Resolution: Done

Problem was fixed in mvel template engine. Fix will be included in 4.0.1 release.

Thank you for reporting and providing such a good test case.




> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 09:29:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Aug 2007 09:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1110) Rules with 'From'
 condition with another not using From causes problem
In-Reply-To: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12986666.1188134958308.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1110:
-----------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

Arjun,

Can you please provide a self contained test case? I was not able to reproduce the problem with trunk (revision #14592) and our test classes.

Thanks
Edson

> Rules with 'From' condition with another not using From causes problem
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1110
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Decision tables
>    Affects Versions:  4.0.0.GA
>         Environment: Any
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> Test case:
> Write a Rule that uses a From clause and on another object does not use a from clause:
> example:
> #From row number: 28
> rule "Rules_28"
> 	
> 	when
> 		cntct: Contact(initialized==true)
> 		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
> 		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
> 	then
>                              System.out.println("Fired 28");
> end
> If All 3 are true:
>  1. Delete Condition 2 --> Rule fires
>  2. Delete COnditon 3 (But keep 2) --> Rule fires
>  3. Keep 2 & 3 (with 1) --> Rule does not fire
> Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.
> Please see if it is 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 lists.jboss.org  Sun Aug 26 10:37:27 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Aug 2007 10:37:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4632) Remove JBCACHE-1172
	workaround
Message-ID: <19809688.1188139047073.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove JBCACHE-1172 workaround
------------------------------

                 Key: JBAS-4632
                 URL: http://jira.jboss.com/jira/browse/JBAS-4632
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.0.0.GA


JBossCacheService.getAttrributes() has a small hacky workaround to JBCACHE-1172. Remove it once a JBC version with a fix is integrated in AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:02:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
Message-ID: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule not firing when expression contains nested accessors
---------------------------------------------------------

                 Key: JBRULES-1136
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Wintel XP Pro SP2
            Reporter: sergey manukyan
         Assigned To: Mark Proctor


Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:

For example :

when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES

when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE

I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22532682.1188151458459.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: TestBug.java

JUnit Test Case

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1755096.1188151458613.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: TestSupplier.java

Test domain object

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27227339.1188151458770.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: TestBusinessStatus.java

Test domain object

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17406440.1188151458943.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: RuleBaseFacade.java

Facade used to get RuleBase

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:06:22 2007
From: jira-events at lists.jboss.org (Sergey Manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:06:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32355164.1188151582145.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sergey Manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: action_rules.drl

test rules

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Mark Proctor
>         Attachments: action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:54:28 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Aug 2007 14:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-849) DynamicRulesTest
 fails with JDK 1.6
In-Reply-To: <15921984.1178878322365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11604705.1188154468517.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli resolved JBRULES-849.
-----------------------------------

    Fix Version/s: 4.0.1
                       (was: FUTURE)
       Resolution: Done

Mark fixed this when did the changes on the PackageClassLoader. Fix included in 4.0.1.

> DynamicRulesTest fails with JDK 1.6
> -----------------------------------
>
>                 Key: JBRULES-849
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-849
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.0.MR2
>         Environment: Linux, JDK 1.6
>            Reporter: Lars Ivar Igesund
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I'm doing mvn install from trunk, using JDK 1.6 on Kubuntu Linux.
> For module drools-compiler, testDynamicFunction in the file below results in an  ERROR 
>  drools-compiler/src/test/java/org/drools/integrationtests/DynamicRulesTest.java
> The contents of drools-compiler/target/surefire-reports/org.drools.integrationtests.DynamicRulesTest.txt are
> ------------------------------------------------------------------------------
> Test set: org.drools.integrationtests.DynamicRulesTest
> -------------------------------------------------------------------------------
> Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.008 sec <<< FAILURE!
> testDynamicFunction(org.drools.integrationtests.DynamicRulesTest)  Time elapsed: 0.036 sec  <<< ERROR!
> java.lang.NoClassDefFoundError: org/drools/test/AddFive
>     at org.drools.test.Rule_global_rule_test_0.consequence(Rule_global_rule_test_0.java:9)
>     at org.drools.test.Rule_global_rule_test_0ConsequenceInvoker.evaluate(Rule_global_rule_test_0ConsequenceInvoker.java:20)
>     at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:497)
>     at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:461)
>     at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:372)
>     at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:353)
>     at org.drools.integrationtests.DynamicRulesTest.testDynamicFunction(DynamicRulesTest.java:312)
>     at org.drools.integrationtests.DynamicRulesTest.testDynamicFunction(DynamicRulesTest.java:312)
>     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 sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
>     at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>     at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>     at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>     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 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
>     at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:17:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9845360.1188163038293.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen resolved JBRULES-1129.
-------------------------------------

    Resolution: Done

Fixed by working around an eclipse jdt code completion bug.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:19:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1057) properties
 keyword list is missing memberof
In-Reply-To: <11968073.1186139929349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2209186.1188163158273.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen resolved JBRULES-1057.
-------------------------------------

    Resolution: Done

> properties keyword list is missing memberof
> -------------------------------------------
>
>                 Key: JBRULES-1057
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1057
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>
> Can you liaise with Edson, make sure all the correct properties are in syntax highlighting and auto completion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:21:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1108) Eclipse DRL
 editor unusable on dark background
In-Reply-To: <28516158.1187748618463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3260030.1188163278951.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen reassigned JBRULES-1108:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)

> Eclipse DRL editor unusable on dark background
> ----------------------------------------------
>
>                 Key: JBRULES-1108
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1108
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.3.0
>            Reporter: Luke Maurer
>         Assigned To: Kris Verlaenen
>             Fix For: FUTURE
>
>
> Having a dark background color for editors in Eclipse makes the default DRL syntax highlighting unusable (as is the case with most Eclipse editors). Unfortunately, the editor's syntax highlighting can be neither changed nor disabled, so the DRL editor is completely unusable for me. While fully customizable syntax highlighting would be the best, simply being able to disable it entirely (and use Eclipse's default text color, which I of course have set to white) would be a perfectly good workaround.
> I set the background color to black in Preferences -> General -> Editors -> Text Editors -> Background color, and the foreground color to white on the same page.
> (Of course, this is really Eclipse's fault for forcing every single editor to have its very own ad-hoc syntax highlighting configuration system ... but I'd better not get started :-) )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:21:19 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:21:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1130) Code completion
 does not work for two char operator symbols
In-Reply-To: <22006280.1188059058281.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13122980.1188163279146.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen updated JBRULES-1130:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Code completion does not work for two char operator symbols
> -----------------------------------------------------------
>
>                 Key: JBRULES-1130
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1130
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: FUTURE
>
>         Attachments: screenshot-1.jpg
>
>
> When typing the first char of an operator, it does not show you the correct matches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:21:20 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:21:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1108) Eclipse DRL
 editor unusable on dark background
In-Reply-To: <28516158.1187748618463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22182233.1188163280421.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen updated JBRULES-1108:
------------------------------------

    Fix Version/s: FUTURE

> Eclipse DRL editor unusable on dark background
> ----------------------------------------------
>
>                 Key: JBRULES-1108
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1108
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.3.0
>            Reporter: Luke Maurer
>         Assigned To: Kris Verlaenen
>             Fix For: FUTURE
>
>
> Having a dark background color for editors in Eclipse makes the default DRL syntax highlighting unusable (as is the case with most Eclipse editors). Unfortunately, the editor's syntax highlighting can be neither changed nor disabled, so the DRL editor is completely unusable for me. While fully customizable syntax highlighting would be the best, simply being able to disable it entirely (and use Eclipse's default text color, which I of course have set to white) would be a perfectly good workaround.
> I set the background color to black in Preferences -> General -> Editors -> Text Editors -> Background color, and the foreground color to white on the same page.
> (Of course, this is really Eclipse's fault for forcing every single editor to have its very own ad-hoc syntax highlighting configuration system ... but I'd better not get started :-) )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:29:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4352853.1188163758283.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=comments#action_12373913 ] 
            
Kris Verlaenen commented on JBRULES-1131:
-----------------------------------------

This is caused because the error thrown by the parser does not contain enough information.
The parser contains a fromDescr, which should have a lineNumber.
The IDE will then use this lineNumber and also create a marker.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sun Aug 26 17:31:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31097917.1188163878338.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Kris Verlaenen reassigned JBRULES-1131:
---------------------------------------

    Assignee: Edson Tirelli  (was: Kris Verlaenen)

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sun Aug 26 19:29:18 2007
From: jira-events at lists.jboss.org (Matthew Robinson (JIRA))
Date: Sun, 26 Aug 2007 19:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4633) ClientAbortException
 stacktrace lines log as separate Log4J events.
Message-ID: <3153777.1188170958334.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClientAbortException stacktrace lines log as separate Log4J events.
-------------------------------------------------------------------

                 Key: JBAS-4633
                 URL: http://jira.jboss.com/jira/browse/JBAS-4633
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-4.0.5.GA
         Environment: SuSE Linux 10.0
            Reporter: Matthew Robinson
         Assigned To: Remy Maucherat
            Priority: Minor


A ClientAbortException is raised legitimately when an end-user closes thier browser before the web app is finished responding to the request.

However, when the stacktrace is generated, it seems that each line is being logged using separate Log4J logger.log() call.  This results in a nice looking file-base log:

2007-08-27 09:10:31,402 ERROR [STDERR] ClientAbortException:  java.net.SocketException: Broken pipe
2007-08-27 09:10:31,640 ERROR [STDERR]  at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:366)
2007-08-27 09:10:31,937 ERROR [STDERR]  at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:353)
2007-08-27 09:10:32,131 ERROR [STDERR]  at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392)
2007-08-27 09:10:32,326 ERROR [STDERR]  at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
2007-08-27 09:10:32,607 ERROR [STDERR]  at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:88)
...

But it causes unnecessary grief and clutter when using SMTP to log errors.  Each line results in a separate email!  So my inbox fills with an average of 60 emails per ClientAbortException!

This problem seems to confined to the ClientAbortException.  Other errors log the stacktrace as a single Log4J event.  Please may I have this error logged in the same way?

Ta.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 20:00:29 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sun, 26 Aug 2007 20:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1173)
 o.j.c.u.ThreadGate does not implement timeouts properly
Message-ID: <17723921.1188172829784.JavaMail.jira@cloud.prod.atl2.jboss.com>

o.j.c.u.ThreadGate does not implement timeouts properly
-------------------------------------------------------

                 Key: JBCACHE-1173
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1173
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Jason T. Greene
         Assigned To: Jason T. Greene


This should be rewritten to use j.u.c Condition instead of object.wait()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 20:57:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Sun, 26 Aug 2007 20:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1119)
 "ExpanderResolver was not
 set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16154025.1188176238677.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1119?page=comments#action_12373919 ] 
            
Michael Neale commented on JBRULES-1119:
----------------------------------------

Is the ant task for this something you have written? as the DSL file can be read in from anywhere (just not sure what can be done to do this - if you are loading rules from the API you can store things however you want). Or is this the drools-ant module?

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Sun Aug 26 22:28:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 26 Aug 2007 22:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1137) Rules are not
 removed when they have shared nodes
Message-ID: <23465708.1188181698203.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rules are not removed when they have shared nodes
-------------------------------------------------

                 Key: JBRULES-1137
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1137
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 4.0.1


If any nodes are shared in a rule, then the rule is not correctly 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 lists.jboss.org  Sun Aug 26 22:31:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 26 Aug 2007 22:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1137) Rules are not
 removed when they have shared nodes
In-Reply-To: <23465708.1188181698203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27785869.1188181878222.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1137.
---------------------------------

    Resolution: Done

> Rules are not removed when they have shared nodes
> -------------------------------------------------
>
>                 Key: JBRULES-1137
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1137
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If any nodes are shared in a rule, then the rule is not correctly 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 lists.jboss.org  Mon Aug 27 02:02:18 2007
From: jira-events at lists.jboss.org (sreeni sabapathy (JIRA))
Date: Mon, 27 Aug 2007 02:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12942126.1188194538341.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373928 ] 
            
sreeni sabapathy commented on JBRULES-1121:
-------------------------------------------

Thank you for the quick response.

"=" would do the calculation, but calculation is based on values of other variables.

Here the rule itself does the calculation for the S.I, that is 

SI = P*T*R/100

writing the above in drools 3.0 it would be

then

m.setSimpleInterest(m.getPrinciple()*m.getTime()*m.getRate()/100);

While considering the drools-jbrms, I am not able to look up the values of other variables in "then" part, 

presently the calculation written in drools-jbrms is just 

SI =100*6*5/100;

but I wanted to have it as 

SI = P*T*R/100; 

The above can be achieved through the option "Bussiness rule through dsl(text editor)". As jbrms is defined for not technical user ( Bussiness user ) I would appreciate if above facility is avaliable in "Bussiness rule (using guided editor)".


> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 02:59:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 27 Aug 2007 02:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17973492.1188197958306.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373935 ] 
            
Michael Neale commented on JBRULES-1121:
----------------------------------------

If you use "=" - you can do similar to what you would do in DRL for that fields value: 
eg, try: 
m.principle * m.time * (m.rate /100)

This of course assumes you have "m" bound on the left hand side of a rule. 

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 03:29:22 2007
From: jira-events at lists.jboss.org (sreeni sabapathy (JIRA))
Date: Mon, 27 Aug 2007 03:29:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11822759.1188199762051.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373937 ] 
            
sreeni sabapathy commented on JBRULES-1121:
-------------------------------------------

The calculation box does not take in any alphabets,but it takes in special characters and numerals, as the "SI" is of float data type.

If the variable is of string type it takes all the keys.

can you please suggest me in how to remove the data type validation in jbrms.

What my idea is, in the "when" part, we have an option of "bound with variable", similar to it can we have "computation on variables" in "then" part.The functionality will be same, just the difference in usage.

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 04:19:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 27 Aug 2007 04:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25132212.1188202758923.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Carlo de Wolf updated EJBTHREE-1025:
------------------------------------

    Description: 
>From the API doc:
"When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."

Thus the following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

  was:
The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

There is a test for this construct in Branch_4_2.


> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 04:45:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 04:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-583) Create JChannel based
 on XML file and stack name (similar to MuxChannel creation)
Message-ID: <4196328.1188204318219.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create JChannel based on XML file and stack name (similar to MuxChannel creation)
---------------------------------------------------------------------------------

                 Key: JGRP-583
                 URL: http://jira.jboss.com/jira/browse/JGRP-583
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.7


Example: Channel ch=new JChannel("stacks.xml", "udp"). This creates a UDP based protocol stack, based on stacks.xml. The advantage is to maintain all protocol stack configurations in the same 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 lists.jboss.org  Mon Aug 27 04:56:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 04:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-409) Channel bundling
In-Reply-To: <24082841.1168897432592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2705414.1188204978228.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Correction: no, it won't. Without logical addresses, channel bundling will only work with UDP. Use IP Bonding or something similar to do the same for TCP

> Channel bundling
> ----------------
>
>                 Key: JGRP-409
>                 URL: http://jira.jboss.com/jira/browse/JGRP-409
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> We can distributed traffic across multiple sockets in the transport. E.g. if we have eth0 and eth1, and both are 100Mbps *full duplex*, then we should be able to send 100Mbps on eth0 and 100Mbps on eth1 *simultaneously*.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 06:30:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 06:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1641) Portal link
 (top right of page) in admin results in 403 error
In-Reply-To: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22212131.1188210618431.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1641?page=comments#action_12373948 ] 
            
Thomas Heute commented on JBPORTAL-1641:
----------------------------------------

It shouldn't with a fresh database. Can you confirm ?

> Portal link (top right of page) in admin results in 403 error
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1641
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.8 Final
>            Reporter: Chris Laprun
>             Fix For: 2.8 Final
>
>
> Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 06:32:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 06:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10429650.1188210738315.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1648:
-----------------------------------

    Fix Version/s: 2.6.2 Final
         Assignee: Thomas Heute

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 06:34:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 06:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4634) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.0.SP4)
Message-ID: <21208408.1188210858201.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss remoting to v2.2.2.GA (from v2.2.0.SP4)
-----------------------------------------------------

                 Key: JBAS-4634
                 URL: http://jira.jboss.com/jira/browse/JBAS-4634
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Dimitris Andreadis
             Fix For:  JBossAS-5.0.0.Beta3


Upgrade to latest remoting 2.2.2.GA when it becomes available.

Upgraded to jboss remoting 2.2.1.GA in the meantime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 07:18:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 07:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31834321.1188213498226.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Library tidy up #1

a) Synch with AS 4.2.x
xdoclet to 1.2.3-brew (from 1.2b3) 
remoting to 2.2.1 for now and eventually to 2.2.2 when available (now at 2.2.0.SP4) 

b) Remove duplicate dom4j entry 1.6.1jboss, leave 1.6.1-brew

    <componentref name="dom4j" version="1.6.1-brew"/>
    <componentref name="dom4j" version="1.6.1jboss"/> 

c) Remove

- unused wutka-dtdparser
  (build/runtime time dependency of jbossxb needed for DTD-based marshalling which is not used in the AS.)
- backport-concurrent
- jbossretro 


> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:29:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Mon, 27 Aug 2007 08:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1110) Rules with
 'From' condition with another not using From causes problem
In-Reply-To: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29471236.1188217758327.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1110?page=comments#action_12373958 ] 
            
Arjun Dhar commented on JBRULES-1110:
-------------------------------------

ok, will do so this weekend. Kindly do not close the bug till then. I'l lalso do some testing and verification at my end. The from works over a JDBC Connections. The actual code is really big with the base classes etc; so will try and dev a scaled down test case to help you.

In the process I may discover things myself. Kindly wait till this weekend, next monday before you decide to close this bug.

Thanks

> Rules with 'From' condition with another not using From causes problem
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1110
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: Any
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> Test case:
> Write a Rule that uses a From clause and on another object does not use a from clause:
> example:
> #From row number: 28
> rule "Rules_28"
> 	
> 	when
> 		cntct: Contact(initialized==true)
> 		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
> 		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
> 	then
>                              System.out.println("Fired 28");
> end
> If All 3 are true:
>  1. Delete Condition 2 --> Rule fires
>  2. Delete COnditon 3 (But keep 2) --> Rule fires
>  3. Keep 2 & 3 (with 1) --> Rule does not fire
> Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.
> Please see if it is 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 lists.jboss.org  Mon Aug 27 08:33:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1138) MVEL code
 completion does not work for objects as params
Message-ID: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>

MVEL code completion does not work for objects as params
--------------------------------------------------------

                 Key: JBRULES-1138
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:33:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Mon, 27 Aug 2007 08:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1111) Final methods
 of POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22161720.1188217998538.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=comments#action_12373960 ] 
            
Arjun Dhar commented on JBRULES-1111:
-------------------------------------

Hi,
  true; but this needs to be documented. From an end user perrspective it is still unexpected behaviour. So kindly add it to your documentation. The version I have does not reflect this fact. For this i dont think its necessary to reopen or issue a new bug, but would be thoughtful if it can be or is already proved in the formal released docs.

Thanks

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:35:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for objects as params
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17040182.1188218118282.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1138:
----------------------------------

    Attachment: screenshot-1.jpg

code completion not working

> MVEL code completion does not work for objects as params
> --------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:37:22 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:37:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for objects as params
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23874923.1188218242176.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1138:
----------------------------------

    Attachment: screenshot-2.jpg

code completion working

> MVEL code completion does not work for objects as params
> --------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:37:22 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 08:37:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-203) Primary Partiton
 approach for handling of partitions
Message-ID: <28454553.1188218242309.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

I added documentation to the manual at http://www.jgroups.org/javagroupsnew/docs/manual/html/index.html ("handling network partitions").

> Primary Partiton approach for handling of partitions
> ----------------------------------------------------
>
>                 Key: JGRP-203
>                 URL: http://jira.jboss.com/jira/browse/JGRP-203
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: PRIMARY_PARTITION.java
>
>
> Add this approach to JGroups. Members in a non-primary partition will shut down, become read-only etc.
> Google for "primary partition AND group communication" for the relevant literature on 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 lists.jboss.org  Mon Aug 27 08:39:29 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 08:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-203) Primary Partiton
 approach for handling of partitions
Message-ID: <33039147.1188218369547.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban resolved JGRP-203.
---------------------------

    Resolution: Done

This functionality doesn't require an additional protocol, and can be handled entirely by writing code in the viewAccepted() callback. There is an example PrimaryPartitionTest which demos this.

> Primary Partiton approach for handling of partitions
> ----------------------------------------------------
>
>                 Key: JGRP-203
>                 URL: http://jira.jboss.com/jira/browse/JGRP-203
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: PRIMARY_PARTITION.java
>
>
> Add this approach to JGroups. Members in a non-primary partition will shut down, become read-only etc.
> Google for "primary partition AND group communication" for the relevant literature on 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 lists.jboss.org  Mon Aug 27 08:48:26 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:48:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1139) code completion
 doesn't work as you type
Message-ID: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>

code completion doesn't work as you type
----------------------------------------

                 Key: JBRULES-1139
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:50:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:50:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27020572.1188219050116.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1139:
----------------------------------

    Attachment: screenshot-1.jpg

Correctly shows the field names

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:50:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:50:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23601026.1188219050547.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1139:
----------------------------------

    Attachment: screenshot-2.jpg

This is after I press 'n' see it does not show the fields, ony matching methods.

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:07:18 2007
From: jira-events at lists.jboss.org (Sergey Manukyan (JIRA))
Date: Mon, 27 Aug 2007 09:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5241341.1188220038691.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sergey Manukyan updated JBRULES-1136:
-------------------------------------

    Description: 
Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:

For example :

when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES

when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE

I am using StatefulSession.  Will attach the unit test to reproduce the problem.

Just found same issue happens in other construct like collect :

when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES


  was:
Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:

For example :

when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES

when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE

I am using StatefulSession.  Will attach the unit test to reproduce the problem.


> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Mark Proctor
>         Attachments: action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:11:18 2007
From: jira-events at lists.jboss.org (Sergey Manukyan (JIRA))
Date: Mon, 27 Aug 2007 09:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24430661.1188220278324.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Sergey Manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: action_rules.drl

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Mark Proctor
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:30:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 27 Aug 2007 09:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26054406.1188221419005.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12373980 ] 
            
Carlo de Wolf commented on EJBTHREE-1025:
-----------------------------------------

Make sure the error references this issue.

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:34:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1111) Final methods
 of POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4106483.1188221658374.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=comments#action_12373981 ] 
            
Edson Tirelli commented on JBRULES-1111:
----------------------------------------

Arjun, 

Yes, agreed. Will do it.


> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:34:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31104053.1188221658525.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reopened JBRULES-1111:
------------------------------------

             
Reopening ticket to update documentation.

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:36:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21726086.1188221778336.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli updated JBRULES-1111:
-----------------------------------

      Component/s: Documentation
    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: FUTURE
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:36:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13867689.1188221778579.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Edson Tirelli reassigned JBRULES-1136:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Edson Tirelli
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:53:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 09:53:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1623) Create "Admin"
 icon for the different themes for the new admin portlet mode
In-Reply-To: <19138744.1186510029362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12320562.1188222799348.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1623.
------------------------------------

    Fix Version/s:     (was: 2.6.3 Final)
       Resolution: Partially Completed
         Assignee: Thomas Heute  (was: Julien Viet)

Not great but done.

> Create "Admin" icon for the different themes for the new admin portlet mode
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1623
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1623
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 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 lists.jboss.org  Mon Aug 27 09:53:19 2007
From: jira-events at lists.jboss.org (Huishan Zhou (JIRA))
Date: Mon, 27 Aug 2007 09:53:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <30881312.1188222799547.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Huishan Zhou updated JBRULES-1112:
----------------------------------

    Complexity: Medium

This morning, I tested drools-jbrms.war (without any change to this war) downloaded from 
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules/drools-4.0.1.SNAPSHOT-brms.zip 
 and tested on standalone Jetty-6.1.1 with three jar files, jboss-faces.jar, jsf-impl.jar and jsf-api.jar, added in the lib directory of Jetty server, downloaded from the site 
http://www.icefaces.org/JForum/posts/downloadAttach/1321.page 

I got the following error:
Failed startup of context org.mortbay.jetty.webapp.WebAppContext at ....drools-jbrms,...
org.drools.repository.RulesRepositoryException: javax.jcr.RepositoryException
...

Would you mind to send me your three jar files for me to test?
Regards,



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: FUTURE
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Mon Aug 27 11:00:27 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Mon, 27 Aug 2007 11:00:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1641) Portal link
 (top right of page) in admin results in 403 error
In-Reply-To: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21760249.1188226827223.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1641?page=comments#action_12374000 ] 
            
Chris Laprun commented on JBPORTAL-1641:
----------------------------------------

Indeed, the issue doesn't exist with a clean DB.

> Portal link (top right of page) in admin results in 403 error
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1641
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.8 Final
>            Reporter: Chris Laprun
>             Fix For: 2.8 Final
>
>
> Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:06:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 11:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1641) Portal link
 (top right of page) in admin results in 403 error
In-Reply-To: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16251750.1188227178419.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1641.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

So i close it :)

In 2.6.2 it is fixed in a different way (slightly less clean) that doesn't require to wipe out the DB.


> Portal link (top right of page) in admin results in 403 error
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1641
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.8 Final
>            Reporter: Chris Laprun
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final
>
>
> Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:18:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 11:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31143582.1188227898344.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1614.
------------------------------------

    Resolution: Done

Fixed

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:28:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4635) Fix
	jboss-head-testsuite-sun-1.5
Message-ID: <20812922.1188228498190.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix jboss-head-testsuite-sun-1.5
--------------------------------

                 Key: JBAS-4635
                 URL: http://jira.jboss.com/jira/browse/JBAS-4635
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Dimitris Andreadis
             Fix For:  JBossAS-5.0.0.Beta3


Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5

Create subtasks for groups of 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 lists.jboss.org  Mon Aug 27 11:32:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4635) Fix
	jboss-head-testsuite-sun-1.5
In-Reply-To: <20812922.1188228498190.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3618408.1188228738291.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4635:
-------------------------------------

    Description: 
Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5

Create subtasks for groups of failing tests.

Initial count:

3369 122 226 89.67%

  was:
Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5

Create subtasks for groups of failing tests.


> Fix jboss-head-testsuite-sun-1.5
> --------------------------------
>
>                 Key: JBAS-4635
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4635
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Dimitris Andreadis
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5
> Create subtasks for groups of failing tests.
> Initial count:
> 3369 122 226 89.67%

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:45:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4636) Fix
 org.jboss.test.deployers.* failures
Message-ID: <7103086.1188229518425.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.deployers.* failures
---------------------------------------

                 Key: JBAS-4636
                 URL: http://jira.jboss.com/jira/browse/JBAS-4636
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Dimitris Andreadis
             Fix For:  JBossAS-5.0.0.Beta3


Looking at the testsuite runs:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html

There is a whole group of deployer tests that need to be further qualified/fixed, with linked issues created

org.jboss.test.deployers.client.test 4 4 0 6.208 
org.jboss.test.deployers.ear.test 5 5 0 10.343 
org.jboss.test.deployers.ejb.test 4 4 0 9.456 
org.jboss.test.deployers.jbas2904.test 1 1 0 1.659 
org.jboss.test.deployers.rar.test 4 4 0 6.285 
org.jboss.test.deployers.sar.test 4 4 0 16.937 
org.jboss.test.deployers.web.test 4 4 0 30.319 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:49:18 2007
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 27 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4636) Fix
 org.jboss.test.deployers.* failures
In-Reply-To: <7103086.1188229518425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27992496.1188229758507.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Ales Justin reassigned JBAS-4636:
---------------------------------

    Assignee: Ales Justin

> Fix org.jboss.test.deployers.* failures
> ---------------------------------------
>
>                 Key: JBAS-4636
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4636
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Ales Justin
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Looking at the testsuite runs:
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html
> There is a whole group of deployer tests that need to be further qualified/fixed, with linked issues created
> org.jboss.test.deployers.client.test 4 4 0 6.208 
> org.jboss.test.deployers.ear.test 5 5 0 10.343 
> org.jboss.test.deployers.ejb.test 4 4 0 9.456 
> org.jboss.test.deployers.jbas2904.test 1 1 0 1.659 
> org.jboss.test.deployers.rar.test 4 4 0 6.285 
> org.jboss.test.deployers.sar.test 4 4 0 16.937 
> org.jboss.test.deployers.web.test 4 4 0 30.319 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:55:32 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:55:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4637) Fix
 org.jboss.test.messaging.* tests
Message-ID: <30496584.1188230132824.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.messaging.* tests
------------------------------------

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


http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html

The failing messaging tests need to be looked-up and further qualified or fixed. The failures are not necessarily messaging related:

SecurityUnitTestCase 30 0 9 21.235 
SecurityUnitTestCase(tests-jbossmessaging) 30 0 10 33.938 
SessionCloseStressTestCase(tests-standard-stress) 1 1 0 0.000 

UnackedUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:55:32 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:55:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4637) Fix
 org.jboss.test.messaging.* tests
In-Reply-To: <30496584.1188230132824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15425472.1188230132997.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis reassigned JBAS-4637:
----------------------------------------

    Assignee: Clebert Suconic

Clebert, can you help?

> Fix org.jboss.test.messaging.* tests
> ------------------------------------
>
>                 Key: JBAS-4637
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4637
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html
> The failing messaging tests need to be looked-up and further qualified or fixed. The failures are not necessarily messaging related:
> SecurityUnitTestCase 30 0 9 21.235 
> SecurityUnitTestCase(tests-jbossmessaging) 30 0 10 33.938 
> SessionCloseStressTestCase(tests-standard-stress) 1 1 0 0.000 
> UnackedUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 12:04:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 27 Aug 2007 12:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4637) Fix
 org.jboss.test.messaging.* tests
In-Reply-To: <30496584.1188230132824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5129199.1188230658314.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4637?page=comments#action_12374015 ] 
            
Clebert Suconic commented on JBAS-4637:
---------------------------------------

SecurityUnitTestCase looks like something wrong on security... The same test pass on 4.2 without any changes... I will verify

> Fix org.jboss.test.messaging.* tests
> ------------------------------------
>
>                 Key: JBAS-4637
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4637
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html
> The failing messaging tests need to be looked-up and further qualified or fixed. The failures are not necessarily messaging related:
> SecurityUnitTestCase 30 0 9 21.235 
> SecurityUnitTestCase(tests-jbossmessaging) 30 0 10 33.938 
> SessionCloseStressTestCase(tests-standard-stress) 1 1 0 0.000 
> UnackedUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 12:39:23 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Aug 2007 12:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1174) Add further
	passivation docs
Message-ID: <8204338.1188232763535.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add further passivation docs
----------------------------

                 Key: JBCACHE-1174
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1174
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Cache loaders
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: 2.1.0.GA


Add discussion a la http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077805#4077805. I've already done this in my local checkout but can't figure out how to get the maven jdocbook stuff to run so I can validate.  This task is just a reminder to finish up once a more urgent need drives me to figure this stuff 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 lists.jboss.org  Mon Aug 27 12:47:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 12:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4638) fix
 org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web
 2.0.1.CR6.
Message-ID: <14167343.1188233238869.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web 2.0.1.CR6.
-----------------------------------------------------------------------------------------

                 Key: JBAS-4638
                 URL: http://jira.jboss.com/jira/browse/JBAS-4638
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Dimitris Andreadis
         Assigned To: Remy Maucherat
             Fix For: JBossAS-4.2.2.GA


see http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-sun-1.5?log=log20070821220014

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 13:01:32 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Aug 2007 13:01:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4639) Optimized
 replication of ClusteredSession metadata
Message-ID: <10945788.1188234092145.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimized replication of ClusteredSession metadata
--------------------------------------------------

                 Key: JBAS-4639
                 URL: http://jira.jboss.com/jira/browse/JBAS-4639
             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


Stop storing clustered session metadata as a single key value pair in JBossCache.  Instead, separate those attributes prone to frequent change (s/b just the access timestamp) from those that are largely fixed at session creation.  Call cache.put() with the "fixed" ones only on the first request (or in the less likely event that something changes in them, e.g. timeout interval, in a later request.)  Store the timestamp with every request; perhaps less often if the request didn't change anything else in the session, i.e. no more often than every 30 secs.

With this we can get rid of hacky stuff like using Subject/Observer to track FIELD granularity pojo attribute changes.  We just do that so we know whether to replicate session the metadata.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 14:25:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 14:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1138) MVEL code
 completion does not work for objects as params
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16734537.1188239118419.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1138?page=comments#action_12374048 ] 
            
Philippe Ombredanne commented on JBRULES-1138:
----------------------------------------------

Ok, this has nothing to do with params, but with the fact we are asking completion for an nested expression, which is not yet syntactically correct mvel wise.
textArea.append ( $p 
will not compile in mvel, so we need to think about a way to transform that back into a balanced expression that could compile.
In that case the outer expression is irrelevant from a completion point of view. 
We would need to have some code to parse that, such that we can extract the inner expression and use it for completion.

> MVEL code completion does not work for objects as params
> --------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 16:05:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 16:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10068229.1188245118332.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne resolved JBRULES-1139.
------------------------------------------

    Resolution: Done

Fixed @ rev14666

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 16:05:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 16:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12075226.1188245118507.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne reassigned JBRULES-1139:
--------------------------------------------

    Assignee: Mark Proctor  (was: Philippe Ombredanne)

For your review

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 16:07:19 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 16:07:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for nested expressions
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12903239.1188245239028.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne updated JBRULES-1138:
-----------------------------------------

    Summary: MVEL code completion does not work for nested expressions  (was: MVEL code completion does not work for objects as params)

> MVEL code completion does not work for nested expressions
> ---------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 17:17:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 17:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30375755.1188249438407.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne updated JBRULES-1134:
-----------------------------------------

    Description: 
The drools variable appears twice in context compliation, once typed and once as Object.
Actually I could not reproduce that one. 
But in general variables may appear twice.

  was:The drools variable appears twice in context compliation, once typed and once as Object.


> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.
> Actually I could not reproduce that one. 
> But in general variables may appear twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 17:19:30 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 17:19:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24659357.1188249570206.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne resolved JBRULES-1134.
------------------------------------------

    Resolution: Done

Fixe @ rev 14669

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.
> Actually I could not reproduce that one. 
> But in general variables may appear twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 17:19:30 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 17:19:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29555110.1188249570420.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Philippe Ombredanne reassigned JBRULES-1134:
--------------------------------------------

    Assignee: Mark Proctor  (was: Philippe Ombredanne)

For your review

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.
> Actually I could not reproduce that one. 
> But in general variables may appear twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 18:42:24 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 27 Aug 2007 18:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4638) fix
 org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web
 2.0.1.CR6.
In-Reply-To: <14167343.1188233238869.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11192069.1188254544452.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4638?page=comments#action_12374090 ] 
            
Remy Maucherat commented on JBAS-4638:
--------------------------------------

Ok. There are no changes at all in the SSL code, so it's strange. Maybe it relates to the logging update, but it's still completely unexpected.

> fix org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web 2.0.1.CR6.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-4638
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4638
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-4.2.2.GA
>
>
> see http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-sun-1.5?log=log20070821220014

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 20:50:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 27 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2451708.1188262218406.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12374097 ] 
            
Michael Neale commented on JBRULES-1121:
----------------------------------------

I have not been able to reproduce it. If you type "=" as the first character in the text box (talking about "then" of course) then it WILL let you put in numbers (or should). If not, then it is a bug (and we should log it as such). Can you provide more details on this?

Yes I like your idea of the "literal/formula" thing similar to the "when" part (but we want to keep it simple - as most of the time it is literal values or calculations).

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 22:59:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 22:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24672575.1188269958217.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1139:
----------------------------------

    Attachment: screenshot-3.jpg

completion as you type works after the first . operator, but doesn't work on the first root itentifier. notice that "dr" is not showing drools, yet I saw it there if I did ctrl+space before typing "dr".

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 23:01:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 23:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1140) Context Assist
 does not show available declarations and globals
Message-ID: <7063853.1188270078538.JavaMail.jira@cloud.prod.atl2.jboss.com>

Context Assist does not show available declarations and globals
---------------------------------------------------------------

                 Key: JBRULES-1140
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1140
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


when you do context assist at the start of a new statement all globals and declarations are of course available and show show in the context assist list, but 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 lists.jboss.org  Mon Aug 27 23:01:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 23:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1140) Context Assist
 does not show available declarations and globals
In-Reply-To: <7063853.1188270078538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19550725.1188270078716.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor closed JBRULES-1140.
---------------------------------

    Resolution: Cannot Reproduce Bug

sorry ignore that one, was talking rubbish.

> Context Assist does not show available declarations and globals
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1140
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1140
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>
> when you do context assist at the start of a new statement all globals and declarations are of course available and show show in the context assist list, but 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 lists.jboss.org  Mon Aug 27 23:07:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 23:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1141) context assist no
 longer works for functions in the drl.
Message-ID: <17049984.1188270438381.JavaMail.jira@cloud.prod.atl2.jboss.com>

context assist no longer works for functions in the drl.
--------------------------------------------------------

                 Key: JBRULES-1141
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1141
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


context assist no longer works for functions in the drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 04:57:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 04:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4640) JmsActivation
 reconnection could start multiple threads
Message-ID: <3182596.1188291438241.JavaMail.jira@cloud.prod.atl2.jboss.com>

JmsActivation reconnection could start multiple threads
-------------------------------------------------------

                 Key: JBAS-4640
                 URL: http://jira.jboss.com/jira/browse/JBAS-4640
             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.Beta3, JBossAS-4.2.2.GA


The jms inflow resource adapter could start multiple recovery threads if the exception listener is fired
during a reconnect after the connection is established.

There needs to be a guard to make sure only one thread is doing the 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 lists.jboss.org  Tue Aug 28 04:59:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 04:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4640) JmsActivation
 reconnection could start multiple threads
In-Reply-To: <3182596.1188291438241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5963459.1188291558332.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Adrian Brock closed JBAS-4640.
------------------------------

    Resolution: Done

> JmsActivation reconnection could start multiple threads
> -------------------------------------------------------
>
>                 Key: JBAS-4640
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4640
>             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.Beta3, JBossAS-4.2.2.GA
>
>
> The jms inflow resource adapter could start multiple recovery threads if the exception listener is fired
> during a reconnect after the connection is established.
> There needs to be a guard to make sure only one thread is doing the 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 lists.jboss.org  Tue Aug 28 06:17:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 06:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4516) The transaction
 project needs moving out jboss-head since it is obsolete
In-Reply-To: <27290032.1183572051138.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15804145.1188296238517.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis updated JBAS-4516:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078676#4078676

Link to a forum discussion.

> The transaction project needs moving out jboss-head since it is obsolete
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4516
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4516
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.GA
>
>
> The transaction project in jboss-head is obsolete now that it uses JBossTM.
> The subtasks of this task describe what needs doing to complete 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 lists.jboss.org  Tue Aug 28 06:39:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
Message-ID: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>

Generify the lazy list, map and set implementations
---------------------------------------------------

                 Key: JBCOMMON-30
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: core
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For: 2.0.5.GA


Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 06:45:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:45:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
In-Reply-To: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24783881.1188297947943.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-30?page=all ]

Adrian Brock closed JBCOMMON-30.
--------------------------------

    Resolution: Done

> Generify the lazy list, map and set implementations
> ---------------------------------------------------
>
>                 Key: JBCOMMON-30
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.0.5.GA
>
>
> Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 06:45:48 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:45:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
Message-ID: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port generic collections from Microcontainer to common
------------------------------------------------------

                 Key: JBCOMMON-31
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For: 2.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 lists.jboss.org  Tue Aug 28 06:49:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:49:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31854539.1188298159606.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1648.
------------------------------------

    Resolution: Done

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 06:49:20 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:49:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1583) Permissions not
 pruned after deletion of Role
In-Reply-To: <12563377.1184593803835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13669423.1188298160136.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1583:
-----------------------------------

    Fix Version/s:     (was: 2.6.2 Final)

> Permissions not pruned after deletion of Role
> ---------------------------------------------
>
>                 Key: JBPORTAL-1583
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1583
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>             Fix For: 2.8 Final
>
>
> Summary: When a role is deleted, it still shows up in various pwermission screens.
> How to repeat: Create a new role, assign the default portal 'view recursive' permissions for this new role, delete the role, check that permission screen for the default portal and find that the deleted role is still listed there.
> What I expected: When a role is deleted, all associated permissions are removed
> 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 lists.jboss.org  Tue Aug 28 06:53:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1534) Integrate
	netvibes widgets
In-Reply-To: <31207655.1183717973218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1993466.1188298398442.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1534:
-----------------------------------

    Fix Version/s:     (was: 2.6.2 Final)

> Integrate netvibes widgets
> --------------------------
>
>                 Key: JBPORTAL-1534
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1534
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>            Priority: Optional
>             Fix For: 2.8 Final
>
>
> Integrate netvibes widgets into portal- similar way google gadgets are.
> http://dev.netvibes.com/doc/howto/widget_export

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 06:53:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30975529.1188298398590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock updated JBCOMMON-31:
---------------------------------

    Component/s: core

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.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 lists.jboss.org  Tue Aug 28 06:55:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23754698.1188298518378.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock closed JBCOMMON-31.
--------------------------------

    Resolution: Done

Ported the WeakTypeCache the AbstractBuilder helper class
and a generified WeakValueHashMap.

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.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 lists.jboss.org  Tue Aug 28 06:55:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1505) Parameters class
 may have a "protected" internal Map, for overriding
In-Reply-To: <24122424.1182853276600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5505981.1188298518923.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1505:
-----------------------------------

    Fix Version/s:     (was: 2.6.2 Final)

> Parameters class may have a "protected" internal Map, for overriding
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1505
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1505
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 RC3
>            Reporter: Antoine Herzog
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.8 Final
>
>
> The class org.jboss.portlet.util.Parameters has a 
>        private Map parameters;
> put it with protected :
>        protected Map parameters;
> so access it possible when overriding this class.
> Example of needs : 
>        - overriding the the Parameters class to provide access to the collection, etc...
>        - use of our own TotoParameters, inheriting from Parameters, to work it with specific features
> for debugging... log what is in it (the Parameters class provide nothing to get the collection of key, the size() etc...)
> and when overriding and modifying some CommandFactory and URLFactory
> Turnaround : I use a ParametersHelper, to fill the Map of params, manipulate it, debug... 
> and just before to pass it to the portal (end of CommandFactory doMapping method), I build a Parameters instance from it.
> It is ok in this use case, but overriding the class would be much better.
> 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 lists.jboss.org  Tue Aug 28 06:55:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:55:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1525) RichFaces :
 finish integration : features, examples...
In-Reply-To: <30089601.1183547751388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18711004.1188298519225.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1525:
-----------------------------------

    Fix Version/s: 2.6.3 Final
                       (was: 2.6.2 Final)

> RichFaces : finish integration : features, examples...
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1525
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1525
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Samples
>    Affects Versions: 2.6 CR3
>         Environment: JBoss Portal 2.6CR3 (on a JBoss AS 4.0.5)
> Rich Faces 3.0.0 and 3.0.2 (fixed version)
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.3 Final
>
>
> RichFaces has provided a sample application to work in a JBoss Portal Portlet. 
> There was quiet a lot of tuning and adaptation (RichFaces side only ?).
> It seems that it work with the JBoss Portal 2.6.0 as released.
> But they may be some things to do in JBoss Portal side.
>  - Use of RichFaces for admin portlets etc... (as it is now inside JBoss products)
>  - At least, integrate a sample RichFaces Portlet, to show how nice it is, and how it works 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 lists.jboss.org  Tue Aug 28 06:57:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21355847.1188298638664.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12374136 ] 
            
Thomas Heute commented on JBPORTAL-1499:
----------------------------------------

Sohil,
could you close this case as "Won't fix" and open a new one with a correct name and description for it with the planned target release please.



> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 07:04:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 07:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1624) Create icon for
 the admin
 mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
In-Reply-To: <5089473.1186511209298.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19166353.1188299058248.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1624.
------------------------------------

    Resolution: Duplicate Issue

> Create icon for the admin mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
> --------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1624
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1624
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 07:04:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 07:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1625) Portlet mode
 "admin" for portlet administration
In-Reply-To: <32179551.1186516913488.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6322085.1188299058364.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1625.
------------------------------------

    Resolution: Done

> Portlet mode "admin" for portlet administration
> -----------------------------------------------
>
>                 Key: JBPORTAL-1625
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1625
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 07:12:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 07:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1602) IPC example
	wrong in doco
In-Reply-To: <8920649.1184862707178.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15419486.1188299538857.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1602:
--------------------------------------

    Assignee: Thomas Heute  (was: Julien Viet)

> IPC example wrong in doco
> -------------------------
>
>                 Key: JBPORTAL-1602
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1602
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> 10.8.2
>             // We can redirect
>             newEvent = new WindowActionEvent(windowB);
>             newEvent.setParameters(wae.getParameters());
>             // Redirect to the new event
>             return newEvent;
> This causes an exception regarding window state.  This should read as http://anonsvn.jboss.org/repos/portal/trunk/core-samples/src/main/org/jboss/portal/core/samples/basic/event/PortletB.java
>                // We can redirect
>                newEvent = new WindowActionEvent(windowB);
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
>    

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 08:02:35 2007
From: jira-events at lists.jboss.org (andreas kinell (JIRA))
Date: Tue, 28 Aug 2007 08:02:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1142) nested accessors
 on the lhs of
 the memberOf (or not memberOf) operator lead to an exception
Message-ID: <33222909.1188302555335.JavaMail.jira@cloud.prod.atl2.jboss.com>

nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception
-------------------------------------------------------------------------------------------

                 Key: JBRULES-1142
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1142
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Java 1.5, Drools 4.0.0.GA
            Reporter: andreas kinell
         Assigned To: Mark Proctor


nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception:

business logic (pseudocode):

class Position {
   private Instrument instrument;
}
class Instrument {
   private Currency currency;
}

with getters and setters.

rule:

$collection : Collection()
$position : Position(instrument.currency not memberOf $collection)

exception:

org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 1f99eea
	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:212)
	at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:110)
	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:119)
	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
	at test.RuleTest.testRuleEngine1(RuleTest.java:99)
Caused by: java.lang.ClassCastException: test.Currency
	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36)
	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:206)
	... 33 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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
In-Reply-To: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13348394.1188304547622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-30?page=all ]

Adrian Brock reopened JBCOMMON-30:
----------------------------------

             

> Generify the lazy list, map and set implementations
> ---------------------------------------------------
>
>                 Key: JBCOMMON-30
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.1.GA
>
>
> Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
In-Reply-To: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13765624.1188304547736.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-30?page=all ]

Adrian Brock closed JBCOMMON-30.
--------------------------------

    Fix Version/s: 2.2.1.GA
                       (was: 2.0.5.GA)
       Resolution: Done

> Generify the lazy list, map and set implementations
> ---------------------------------------------------
>
>                 Key: JBCOMMON-30
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.1.GA
>
>
> Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <195681.1188304547860.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock reopened JBCOMMON-31:
----------------------------------

             

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24552930.1188304547979.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock closed JBCOMMON-31.
--------------------------------

    Fix Version/s: 2.2.1.GA
                       (was: 2.0.5.GA)
       Resolution: Done

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.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 lists.jboss.org  Tue Aug 28 08:39:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 28 Aug 2007 08:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1143) ClassTypeResolver
 throws an Error
Message-ID: <29742507.1188304758286.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassTypeResolver throws an Error
---------------------------------

                 Key: JBRULES-1143
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1143
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Rule Assemply/SPI
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


would be nicer if it was a better exception (or reported it a bit better) - perhaps. Its pretty buried.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:03:18 2007
From: jira-events at lists.jboss.org (andreas kinell (JIRA))
Date: Tue, 28 Aug 2007 09:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1142) nested
 accessors on the lhs
 of the memberOf (or not memberOf) operator lead to an exception
In-Reply-To: <33222909.1188302555335.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5013027.1188306198681.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1142?page=comments#action_12374159 ] 
            
andreas kinell commented on JBRULES-1142:
-----------------------------------------

After chatting with E.Tirelli it seems that this bug was fixed by a bugfix for a very similar issue.
see this thread regarding 'contains':
http://lists.jboss.org/pipermail/rules-users/2007-August/002356.html


> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception
> -------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1142
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1142
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.5, Drools 4.0.0.GA
>            Reporter: andreas kinell
>         Assigned To: Mark Proctor
>   Original Estimate: 5 hours
>  Remaining Estimate: 5 hours
>
> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception:
> business logic (pseudocode):
> class Position {
>    private Instrument instrument;
> }
> class Instrument {
>    private Currency currency;
> }
> with getters and setters.
> rule:
> $collection : Collection()
> $position : Position(instrument.currency not memberOf $collection)
> exception:
> org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 1f99eea
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:212)
> 	at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:110)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:119)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at test.RuleTest.testRuleEngine1(RuleTest.java:99)
> Caused by: java.lang.ClassCastException: test.Currency
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36)
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:206)
> 	... 33 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 lists.jboss.org  Tue Aug 28 09:05:18 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 28 Aug 2007 09:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4638) fix
 org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web
 2.0.1.CR6.
In-Reply-To: <14167343.1188233238869.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19486711.1188306318271.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Remy Maucherat resolved JBAS-4638.
----------------------------------

    Resolution: Done

As with a previous problem, this was caused by new attribute validation code, which is not compatible with the SSL factories which use arbitrary attributes.

> fix org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web 2.0.1.CR6.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-4638
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4638
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-4.2.2.GA
>
>
> see http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-sun-1.5?log=log20070821220014

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:13:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 09:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-409) Channel bundling
In-Reply-To: <24082841.1168897432592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32649403.1188306798394.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-409:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Revisit this in 2.x. Instead of channel bundling, OS provided mechanisms such as IP Bonding could be used (needs to be verified).
Theoretically, channel bundling could increase performance, as we can partition the traffic across multiple IP multicast addresses.
If we want to do this, maybe we need to revisit logical addresses too.

> Channel bundling
> ----------------
>
>                 Key: JGRP-409
>                 URL: http://jira.jboss.com/jira/browse/JGRP-409
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> We can distributed traffic across multiple sockets in the transport. E.g. if we have eth0 and eth1, and both are 100Mbps *full duplex*, then we should be able to send 100Mbps on eth0 and 100Mbps on eth1 *simultaneously*.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:30:50 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:30:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1580) [PATCH] updated
 helloworld jsf portlet
In-Reply-To: <8511276.1184442783989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6944219.1188307850838.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1580:
--------------------------------------

    Assignee: Thomas Heute

> [PATCH] updated helloworld jsf portlet
> --------------------------------------
>
>                 Key: JBPORTAL-1580
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1580
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Samples
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: helloworldportlet.zip
>
>
> I also uploaded this to portalswap but I'm not sure it is being monitored.  This is an updated version of the helloworldjsf that works on JBP 2.6+JBAS 4.2.  The previous one that was there did NOT work on the 2.6/4.2 combo.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:30:51 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:30:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1581) Update Hello
 World doc and sample to 2.6
In-Reply-To: <32326614.1184462957708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30219938.1188307851054.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1581:
--------------------------------------

    Assignee: Thomas Heute  (was: Xi HUANG)

> Update Hello World doc and sample to 2.6
> ----------------------------------------
>
>                 Key: JBPORTAL-1581
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1581
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide, Portal Samples
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> http://docs.jboss.com/jbportal/v2.6/reference-guide/html_single/#desc_examples
> "To illustrate our example, we have made available a portlet with a page descriptor that you can download here: HelloWorld Page." 
> link is http://anonsvn.jboss.org/repos/portletswap/portlets/2_4/bundles/HelloWorldPortalPage.zip
> There doesn't appear to be a 2.6 version of this and since it is trying to demonstrate descriptors that the doc illustrates have changed between 2.4/2.6 it seems bad to then reference an out of date version from the doco.  While the changes are minor, it should ref the 2.6 dtd and such.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:35:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1604) Window state
 required but has no effect
In-Reply-To: <17779748.1184893247122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21280722.1188308118323.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1604:
--------------------------------------

    Assignee: Julien Viet

> Window state required but has no effect
> ---------------------------------------
>
>                 Key: JBPORTAL-1604
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1604
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> In 2.6 you must do this
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(org.jboss.portal.WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
> when sending an event or you get an error.  However, the window state is completely ignored (the window would not be maximized with the above).  If it is required it should have some effect -- otherwise the api should revert to before where it was not 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 lists.jboss.org  Tue Aug 28 09:45:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1602) IPC example
	wrong in doco
In-Reply-To: <8920649.1184862707178.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7018398.1188308718493.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1602.
------------------------------------

    Resolution: Done

> IPC example wrong in doco
> -------------------------
>
>                 Key: JBPORTAL-1602
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1602
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> 10.8.2
>             // We can redirect
>             newEvent = new WindowActionEvent(windowB);
>             newEvent.setParameters(wae.getParameters());
>             // Redirect to the new event
>             return newEvent;
> This causes an exception regarding window state.  This should read as http://anonsvn.jboss.org/repos/portal/trunk/core-samples/src/main/org/jboss/portal/core/samples/basic/event/PortletB.java
>                // We can redirect
>                newEvent = new WindowActionEvent(windowB);
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
>    

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:52:32 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:52:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1551) Improve file
 upload sample to show how to correctly build a file upload portlet
In-Reply-To: <7536863.1183996472000.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17212084.1188309152812.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1551:
--------------------------------------

    Assignee: Julien Viet

Please assign this to someone, fix this or change the fix version.

I'm not sure what is the 'correct' way :)

I'm also removing all the unassigned issues for JBoss Portal 2.6.2 (either by assigning them or postponing them)

> Improve file upload sample to show how to correctly build a file upload portlet
> -------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1551
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1551
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: FileUploadPortlet.java
>
>
> Retrieving portlet parameters the correct way is not done (cf CharsetPortlet and CMSPortlet bug JBPORTAL-1550 that was not correctly using 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 lists.jboss.org  Tue Aug 28 09:54:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1598) Properly
 support JBoss Cache 1.3.x when running on JBAS 4.2
In-Reply-To: <31296310.1184798747261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6152765.1188309258297.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1598?page=comments#action_12374169 ] 
            
Thomas Heute commented on JBPORTAL-1598:
----------------------------------------

The issue here is to keep supporting 4.0.5 (former JBoss Cache API) and 4.2 (newer JBoss Cache API) (unless we can embed the new one in both AS)

> Properly support JBoss Cache 1.3.x when running on JBAS 4.2
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1598
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1598
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> this blips up w/2.6 on 4.2:
> 2007-07-18 18:29:57,465 INFO  [org.jboss.cache.interceptors.CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 2007-07-18 18:29:57,465 INFO  [org.jboss.cache.interceptors.CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:54:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:54:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1600) inherit
 security constraint between portal Template and dashboards
In-Reply-To: <17178120.1184859228977.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17858199.1188309259136.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1600:
--------------------------------------

    Assignee: Thomas Heute

> inherit security constraint between portal Template and dashboards
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1600
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1600
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Lionel ROSIER
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> we can apply security settings on the template portal, particularly  on the pages.
> but the security constraints are not inherit from the portal Template to the dashboards.
> a page which is secured with a role in the portal template is visible by every users in their dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:58:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1560) pass
 lang/region information
 when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
In-Reply-To: <1693847.1184003024746.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21596683.1188309498812.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1560:
--------------------------------------

    Assignee: Boleslaw Dawidowicz

> pass lang/region information when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1560
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1560
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 09:58:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:58:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1588) Portlet
 instance list should
 "scroll" to the appropriate instance when a new instance is inserted in the
 list outside of the initial range
In-Reply-To: <20605356.1184641847020.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10579981.1188309499945.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reassigned JBPORTAL-1588:
--------------------------------------

    Assignee: Chris Laprun

> Portlet instance list should "scroll" to the appropriate instance when a new instance is inserted in the list outside of the initial range
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1588
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1588
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6 Final, 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Tue Aug 28 10:04:18 2007
From: jira-events at lists.jboss.org (Felipe (JIRA))
Date: Tue, 28 Aug 2007 10:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
Message-ID: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>

message parts with the atribute element won't be accepted by bpel
-----------------------------------------------------------------

                 Key: BPEL-277
                 URL: http://jira.jboss.com/jira/browse/BPEL-277
             Project: JBoss jBPM BPEL
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: jBPM BPEL 1.1 beta 3
         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
            Reporter: Felipe
         Assigned To: Alejandro Guizar


Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )

However, when using the following definitions:
<element name="EE">
  <complexType>
     <sequence>
        <element name="usuario" type="xsd:string"/>
        <element name="sistema" type="xsd:string"/>
     </sequence>
   </complexType>
</element>

<wsdl:message name="pruebaE">
      <wsdl:part name="entrada" element="tns1:EE"/>
</wsdl:message>

<variable name="entradaPruebaE" messageType="BA:pruebaE"/>
    
<copy>
      	<from variable="nombres" />
      	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
 </copy>

It will throw the following exception:
2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
        at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
        at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)

In the addressed part of XPathEvaluator, the following can be read:
  if (!(node instanceof Element)) {
      // cannot create node for a non-element parent
      throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
    }

This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 10:06:39 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 10:06:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-407) Migrate
 microcontainer docbook gen to jdocbook plugin
In-Reply-To: <26415361.1187899278199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8634052.1188309999009.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-407?page=all ]

Paul Gier closed JBBUILD-407.
-----------------------------

    Resolution: Done

Microcontainer build is now using jdocbook plugin.

> Migrate microcontainer docbook gen to jdocbook plugin
> -----------------------------------------------------
>
>                 Key: JBBUILD-407
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-407
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Microcontainer should use the maven-jdocbook-plugin for it's doc generation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 10:11:19 2007
From: jira-events at lists.jboss.org (Dawie Malan (JIRA))
Date: Tue, 28 Aug 2007 10:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1018)
 ClassCastException on
 concurrent EJB3 method invocation from different beans
In-Reply-To: <21528878.1185176830278.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2163664.1188310279308.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1018?page=comments#action_12374175 ] 
            
Dawie Malan commented on EJBTHREE-1018:
---------------------------------------

I see this issue is not assigned yet.  It is a showstopper for us, as we are running multiple JBoss servers and are planning an even bigger installation.  This issue may force us to rethink our architecture if a solution is not found in time. I would appreciate it if it could be scheduled so that we have more or less an idea of how long it is going to remain a problem.

Thanks!

> ClassCastException on concurrent EJB3 method invocation from different beans
> ----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1018
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1018
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>         Environment: Java: JDK 1.5.0_11
> Eclipse: SDK 3.2.2
>            Reporter: Michael Pfeiffer
>         Attachments: deployables.zip, jboss.example.src.zip
>
>
> Two different EJB3 stateless session beans A and B packaged into separate EAR files deployed on the same JBoss instance 
> invoke a method of another stateless session bean C on another JBoss instance that returns an object of a user 
> defined class Value.
> There seems to be a multi-threading issue. 
> Sometimes when both beans concurrently call the method of C an ClassCastException Value is thrown within the remote 
> interface proxy before the result object is returned to the calling bean.
> The class Value and the remote interface for C are packaged into a JAR file within each EAR file inside a "lib" folder.
> If this JAR file is deployed instead and not packaged into the EAR files of bean A and B everything 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 lists.jboss.org  Tue Aug 28 10:52:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 10:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25645866.1188312738614.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Removed ehcache and jbpm.

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 10:58:39 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 10:58:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-189) Validate that IP
 Bonding is supported
Message-ID: <5058543.1188313119880.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-189:
--------------------------

    Fix Version/s: 2.6
                       (was: 2.x)

> Validate that IP Bonding is supported
> -------------------------------------
>
>                 Key: JGRP-189
>                 URL: http://jira.jboss.com/jira/browse/JGRP-189
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8, 2.2.9, 2.2.9.1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Linux specific

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:08:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Tue, 28 Aug 2007 11:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1560) pass
 lang/region information
 when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
In-Reply-To: <1693847.1184003024746.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26419167.1188313698971.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Boleslaw Dawidowicz resolved JBPORTAL-1560.
-------------------------------------------

    Resolution: Done

done

> pass lang/region information when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1560
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1560
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 11:08:20 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 11:08:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-105) GossipRouter should
 additionally listen on IP multicast group and bridge traffic
Message-ID: <14453874.1188313700257.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-105:
--------------------------

    Fix Version/s: 2.7
                       (was: 2.6)

> GossipRouter should additionally listen on IP multicast group and bridge traffic
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-105
>                 URL: http://jira.jboss.com/jira/browse/JGRP-105
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.7
>
>
> GossipRouter should be augmented to not just route traffic between TCP endpoints, but also between an IP multicast group and all TCP endpoints.
> It should be configured with the properties for a (multicast-based) group X, and then forward messages from X to all of its attached endpoints, and vice versa.
> In the future, this concept could be extended to generic bridging functionality, which will allow to construct hierarchical messaging trees, similar to the MBone

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:08:20 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 11:08:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-430) Support accessing
 multiple GossipRouters in TUNNEL
In-Reply-To: <16193776.1173523767661.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8786170.1188313700445.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-430:
--------------------------

    Fix Version/s: 2.7
                       (was: 2.6)

> Support accessing multiple GossipRouters in TUNNEL
> --------------------------------------------------
>
>                 Key: JGRP-430
>                 URL: http://jira.jboss.com/jira/browse/JGRP-430
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.7
>
>
> Multiple GossipRouters can only be used for lookups, not for routing... However, since all traffic to the GR goes out via TUNNEL (as JGroups transport), and TUNNEL uses a RouterStub to send a message to the GR, we could do the following:
>    * the RouterStub is currently configured with the address of *one* GR
>    * a Stub.send() succeeds in connecting to the GR and sending the
>      message, or goes into a state where it tries to reconnect *forever*
>    * I could simply change that to configure the RouterStub with
>      multiple GRs:
>          o for send(), we iterate through the GRs until send() returns
>            true 
> EFFECT: a GossipRouter is not a single point of failure any longer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:10:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Aug 2007 11:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-433) Caller Interceptor
 Chains Are Not Rebuilt
In-Reply-To: <1733027.1183437963987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27730156.1188313818756.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-433?page=all ]

Kabir Khan reassigned JBAOP-433:
--------------------------------

    Assignee: Flavia Rainone

> Caller Interceptor Chains Are Not Rebuilt
> -----------------------------------------
>
>                 Key: JBAOP-433
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-433
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.5.GA, 2.0.0.alpha5
>            Reporter: Flavia Rainone
>         Assigned To: Flavia Rainone
>            Priority: Critical
>             Fix For: 1.5.6.GA, 2.0.0.beta
>
>
> The rebuild process of interceptor chains for caller pointcuts is not taking place correctly: no pointcut rematching is being performed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:10:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-294) Create hudson
 instance for maven build in app server head.
Message-ID: <22220967.1188313819118.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Paul Gier updated JBBUILD-294:
------------------------------

        Summary: Create hudson instance for maven build in app server head.  (was: Create cruisecontrol instance for maven build in app server head.)
    Description: Setup a hudson instance for Maven.  (was: Setup a cruise control instance for Maven.)

> Create hudson instance for maven build in app server head.
> ----------------------------------------------------------
>
>                 Key: JBBUILD-294
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-294
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>    Affects Versions: Maven Build 1.1
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>
> Setup a hudson instance for Maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:12:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:12:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-294) Create hudson
 instance for maven build in app server head.
Message-ID: <23123521.1188313939570.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Paul Gier updated JBBUILD-294:
------------------------------

     Original Estimate: 2 days
    Remaining Estimate: 2 days

> Create hudson instance for maven build in app server head.
> ----------------------------------------------------------
>
>                 Key: JBBUILD-294
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-294
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>    Affects Versions: Maven Build 1.1
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Setup a hudson instance for Maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:12:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:12:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-409) Fix microcontainer
	jdk14 tests.
In-Reply-To: <12323051.1187986218403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19495009.1188313939773.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-409?page=all ]

Paul Gier updated JBBUILD-409:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Fix microcontainer jdk14 tests.
> -------------------------------
>
>                 Key: JBBUILD-409
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-409
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven, JBossRetro
>            Reporter: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Many of the retro build tests for microcontainer are failing.  These are mostly caused by missing features of jboss-retro.  Once the relevant retro issues have been resolved, the tests should be checked again to find remaining 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 lists.jboss.org  Tue Aug 28 11:14:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-408) Figure out a way
 to use alternate pom files in modules.
In-Reply-To: <1559246.1187985875287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3054428.1188314058253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-408?page=all ]

Paul Gier updated JBBUILD-408:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Figure out a way to use alternate pom files in modules.
> -------------------------------------------------------
>
>                 Key: JBBUILD-408
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-408
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Currently the jdk14 builds have to be done as separate modules, because maven is not able to use alternate files (pom-jdk14.xml) in modules.
> This issue has been created to address this in maven: http://jira.codehaus.org/browse/MNG-3150
> Until this issue is resolved, maybe an ant script can be created to build the modules as an aggregate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:14:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-410) Set up retro
 jdk1.4 build and test of microcontainer on hudson.
In-Reply-To: <17193616.1187986589124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32755936.1188314058404.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Paul Gier updated JBBUILD-410:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Set up retro jdk1.4 build and test of microcontainer on hudson.
> ---------------------------------------------------------------
>
>                 Key: JBBUILD-410
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-410
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> A retro build of microcontainer should be set up on hudson so that we can see which tests are failing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:24:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 11:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-564) Unicast from within
 viewAccepted() callback throws exception in UNICAST
In-Reply-To: <10247822.1184996987287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10012507.1188314658307.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Bela Ban updated JGRP-564:
--------------------------

    Fix Version/s: 2.5.1

> Unicast from within viewAccepted() callback throws exception in UNICAST
> -----------------------------------------------------------------------
>
>                 Key: JGRP-564
>                 URL: http://jira.jboss.com/jira/browse/JGRP-564
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>
> Unit test is UnicastUnitTest.testUnicastMessageInCallbackExistingMember(). Swapping lines 505 and 506 in GMS fixes the issue. Stack trace is below.
> The issue is that - since we propagate the new view up the stack first, then down - the viewAccepted() callback gets invoked first, before UNICAST can update its view (done when the new view is propagated down the stack).
> We need to investigate whether swapping lines 505 and 506 breaks JGRP-347
> 7:45:12,375 [WARN] [Incoming Thread,x,192.168.5.2:1959] JChannel.up(): failed calling viewAccepted() in receiver
> java.lang.RuntimeException: java.lang.IllegalArgumentException: 192.168.5.2:1961 is not a member of the group [192.168.5.2:1959] (enabled_members=[])
> 	at org.jgroups.tests.UnicastUnitTest$MyReceiver.viewAccepted(UnicastUnitTest.java:84)
> 	at org.jgroups.JChannel.up(JChannel.java:1099)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:325)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:151)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
> 	at org.jgroups.protocols.FC.up(FC.java:414)
> 	at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:505)
> 	at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:449)
> 	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:661)
> 	at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:160)
> 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> 	at org.jgroups.protocols.UNICAST.up(UNICAST.java:263)
> 	at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:720)
> 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:546)
> 	at org.jgroups.protocols.BARRIER.up(BARRIER.java:122)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
> 	at org.jgroups.protocols.FD.up(FD.java:322)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:298)
> 	at org.jgroups.protocols.MERGE2.up(MERGE2.java:145)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:247)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1486)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1435)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:34:23 2007
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 28 Aug 2007 11:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-975) HA-JNDI
 InitialContext for @Resource annotation
In-Reply-To: <8059294.1180541948420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24583361.1188315263022.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Shelly McGowan reassigned EJBTHREE-975:
---------------------------------------

    Assignee: Shelly McGowan  (was: William DeCoste)

> HA-JNDI InitialContext for @Resource annotation
> -----------------------------------------------
>
>                 Key: EJBTHREE-975
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-975
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Ana Holzbach
>         Assigned To: Shelly McGowan
>             Fix For: AS 4.2.2.GA
>
>
>  We're deploying ejbs in a clustered environment that access JMS topics with @Resource annotation as follows:
>         @Resource(mappedName = "TopicConnectionFactory")
> 	private ConnectionFactory mJmsConnectionFactory;
> 	
> 	@Resource(mappedName = "topic/RoomService/BedStaffUpdate")
> 	private Topic mStaffUpdateTopic; 
>  The topics are deployed in deploy-hasingleton and are available to the singleton master in the cluster only. The remaining nodes get the following error:
>  javax.naming.NameNotFoundException: topic 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:267)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at flex.messaging.services.messaging.adapters.JMSProxy.getDestination(JMSProxy.java:186)
> at flex.messaging.services.messaging.adapters.JMSTopicConsumer.start(JMSTopicConsumer.java:59)
> at flex.messaging.services.messaging.adapters.JMSAdapter.manage(JMSAdapter.java:345)
> at flex.messaging.services.MessageService.manageSubscriptions(MessageService.java:571)
> at flex.messaging.services.MessageService.serviceCommand(MessageService.java:152)
> at flex.messaging.MessageBroker.routeCommandToService(MessageBroker.java:622)
> at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:298)
> at flex.messaging.endpoints.rtmp.AbstractRTMPServer.dispatchMessage(AbstractRTMPServer.java:682)
> at flex.messaging.endpoints.rtmp.NIORTMPConnection$RTMPReader.run(NIORTMPConnection.java:665)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
> or.java:643)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> ava:668)
> at java.lang.Thread.run(Thread.java:595)	
>  See also http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049784#4049784
>  According to Brian Stansberry the @Resource annotations are resolved relative to a default initial context, which will not work for the clustered environment, since we need access to the HA-JNDI context for these. Also according to Brian, getJndiProperties() in DeploymentUnit should be responsible for reading jndi properties defined at deployment through which we might be able to define an HA-JNDI context, but this method returns null in jboss 4.x and also in "2 out of the 3 impls in the AS 5 codebase". See also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109219

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:34:23 2007
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 28 Aug 2007 11:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-975) HA-JNDI
 InitialContext for @Resource annotation
In-Reply-To: <8059294.1180541948420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30066155.1188315263355.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Shelly McGowan reassigned EJBTHREE-975:
---------------------------------------

    Assignee: William DeCoste  (was: Shelly McGowan)

intended to reassign the JBPAPP related issue

> HA-JNDI InitialContext for @Resource annotation
> -----------------------------------------------
>
>                 Key: EJBTHREE-975
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-975
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Ana Holzbach
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.GA
>
>
>  We're deploying ejbs in a clustered environment that access JMS topics with @Resource annotation as follows:
>         @Resource(mappedName = "TopicConnectionFactory")
> 	private ConnectionFactory mJmsConnectionFactory;
> 	
> 	@Resource(mappedName = "topic/RoomService/BedStaffUpdate")
> 	private Topic mStaffUpdateTopic; 
>  The topics are deployed in deploy-hasingleton and are available to the singleton master in the cluster only. The remaining nodes get the following error:
>  javax.naming.NameNotFoundException: topic 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:267)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at flex.messaging.services.messaging.adapters.JMSProxy.getDestination(JMSProxy.java:186)
> at flex.messaging.services.messaging.adapters.JMSTopicConsumer.start(JMSTopicConsumer.java:59)
> at flex.messaging.services.messaging.adapters.JMSAdapter.manage(JMSAdapter.java:345)
> at flex.messaging.services.MessageService.manageSubscriptions(MessageService.java:571)
> at flex.messaging.services.MessageService.serviceCommand(MessageService.java:152)
> at flex.messaging.MessageBroker.routeCommandToService(MessageBroker.java:622)
> at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:298)
> at flex.messaging.endpoints.rtmp.AbstractRTMPServer.dispatchMessage(AbstractRTMPServer.java:682)
> at flex.messaging.endpoints.rtmp.NIORTMPConnection$RTMPReader.run(NIORTMPConnection.java:665)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
> or.java:643)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> ava:668)
> at java.lang.Thread.run(Thread.java:595)	
>  See also http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049784#4049784
>  According to Brian Stansberry the @Resource annotations are resolved relative to a default initial context, which will not work for the clustered environment, since we need access to the HA-JNDI context for these. Also according to Brian, getJndiProperties() in DeploymentUnit should be responsible for reading jndi properties defined at deployment through which we might be able to define an HA-JNDI context, but this method returns null in jboss 4.x and also in "2 out of the 3 impls in the AS 5 codebase". See also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109219

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:34:24 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Tue, 28 Aug 2007 11:34:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10827162.1188315264729.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Andrew Rubinger reassigned EJBTHREE-1025:
-----------------------------------------

    Assignee: Andrew Rubinger  (was: William DeCoste)

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Andrew Rubinger
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 12:02:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 12:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1649) Update
 installation instruction for JBoss AS 4.2.1.GA
Message-ID: <26456958.1188316938512.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update installation instruction for JBoss AS 4.2.1.GA
-----------------------------------------------------

                 Key: JBPORTAL-1649
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1649
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
            Reporter: Thomas Heute
         Assigned To: Thomas Heute
             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 12:08:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 12:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1649) Update
 installation instruction for JBoss AS 4.2.1.GA
In-Reply-To: <26456958.1188316938512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22540806.1188317298716.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1649.
------------------------------------

    Resolution: Done

> Update installation instruction for JBoss AS 4.2.1.GA
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1649
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1649
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 12:10:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 12:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-259) Migrate AOP builds
	to maven
Message-ID: <15523059.1188317418302.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-259?page=all ]

Paul Gier updated JBBUILD-259:
------------------------------

    Remaining Estimate: 1 week  (was: 3 days)

> Migrate AOP builds to maven
> ---------------------------
>
>                 Key: JBBUILD-259
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-259
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>          Time Spent: 1 day
>  Remaining Estimate: 1 week
>
> Migrate AOP builds to maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:14:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4641) Move
 XMLJUnitMultipleResultFormatter from testsuite module to test module
Message-ID: <184925.1188321258850.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move XMLJUnitMultipleResultFormatter from testsuite module to test module
-------------------------------------------------------------------------

                 Key: JBAS-4641
                 URL: http://jira.jboss.com/jira/browse/JBAS-4641
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-4.2.2.GA


In Branch_4_2, this class is located in the testsuite module rather than in test.  In trunk it's in the jboss-test.jar, so logically it belongs in the test module in Branch_4_2.

I need this class to get separate reports of the same EJB3 test under different configs (see EJBTHREE-856).  The EJB3 testsuite setup that tries to use the std ant XMLJUnitResultFormatter with different "extension" attribute values doesn't work.  I don't want to add the testsuite module to the junit task classpath in EJB3; that could have too many unintended side effects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:22:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4642) Fix
 org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase
Message-ID: <32409682.1188321738616.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase
------------------------------------------------------

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


The error message doesn't look very helpful:

testJavaBeanSchemaInitializerInterceptor Failure description expected:<...eanSchemaInitializer[ ]> but was:<...eanSchemaInitializer[]>
junit.framework.ComparisonFailure: description expected:<...eanSchemaInitializer[
   ]> but was:<...eanSchemaInitializer[]>
	at org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase.testJavaBeanSchemaInitializerInterceptor(XMBean2UnitTestCase.java:129)
 

log snipet
...
2007-08-28 20:02:49,906 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://apache.org/xml/features/validation/dynamic set to: true
2007-08-28 20:02:49,906 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Using parser: org.apache.xerces.jaxp.SAXParserImpl at c79809, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Created parser: org.apache.xerces.jaxp.SAXParserImpl at 1ce784b, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://xml.org/sax/features/validation set to: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://xml.org/sax/features/namespaces set to: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://apache.org/xml/features/validation/dynamic set to: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Using parser: org.apache.xerces.jaxp.SAXParserImpl at 1ce784b, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.DescriptorSupportContainer] addChild, {urn:jboss-test:xmbean:2.0}interceptors,org.jboss.mx.metadata.xb.InterceptorsHolder at 9934d4
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanConstructorInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,JNDIBindingService
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanConstructorInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The default no-arg constructor
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, access,read-write
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The root JNDI name of the context the bindings
      are to be added under
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,RootName
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}type,java.lang.String
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, access,read-write
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The JNDI bindings to add under the RootName
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,Bindings
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}type,org.jboss.naming.JNDIBindings
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, impact,ACTION_INFO
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The start lifecycle operation
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,start
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}return-type,void
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, impact,ACTION_INFO
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The stop lifecycle operation
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,stop
2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}return-type,void
2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanNotificationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The bind event notification
2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanNotificationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,bindEvent
2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] testJavaBeanSchemaInitializerInterceptor took 750ms
2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] ==== Stopping testJavaBeanSchemaInitializerInterceptor ====
2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] ==== tornDown org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase ====
...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:26:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
Message-ID: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
-----------------------------------------------------------

                 Key: JBAS-4643
                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Alexey Loubyansky
             Fix For:  JBossAS-5.0.0.Beta3


testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)

 9.162 
testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)

 2.797 
testJBossCmpJdbc Success  0.994 
testWebXml Success  1.930 
testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)

 0.455 
testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)

 0.635 
testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)

 0.825 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:28:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
In-Reply-To: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9735873.1188322098718.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

While there, there also 2 failures in:

org.jboss.test.xml.ExtendedByImportUnitTestCase
testExtended Error Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/ExtendedByImportUnitTestCase.xml at 6,62
org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/ExtendedByImportUnitTestCase.xml at 6,62
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:184)
	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
	at org.jboss.test.xml.JBossXBTestDelegate.unmarshal(JBossXBTestDelegate.java:118)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:119)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:106)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:72)
	at org.jboss.test.xml.ExtendedByImportUnitTestCase.testExtended(ExtendedByImportUnitTestCase.java:55)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: java.lang.ClassCastException: java.lang.String
	at org.jboss.kernel.plugins.deployment.xml.BeanPropertyInterceptor.add(BeanPropertyInterceptor.java:48)
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:1197)
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:248)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:374)
	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
	at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(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:180)
	... 25 more

 
and

org.jboss.test.xml.SingletonSchemaBindingResolverUnitTestCase
testBean Error Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/SingletonSchemaBindingResolverUnitTestCaseContainerStrictBean.xml at 4,2
org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/SingletonSchemaBindingResolverUnitTestCaseContainerStrictBean.xml at 4,2
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:184)
	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
	at org.jboss.test.xml.JBossXBTestDelegate.unmarshal(JBossXBTestDelegate.java:118)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:119)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:106)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:72)
	at org.jboss.test.xml.SingletonSchemaBindingResolverUnitTestCase.testBean(SingletonSchemaBindingResolverUnitTestCase.java:53)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI=dummy://www.jboss.org/container location=null
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:283)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:402)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
	at org.apache.xerces.xinclude.XIncludeHandler.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:180)
	... 25 more

 

> Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
> -----------------------------------------------------------
>
>                 Key: JBAS-4643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
> junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)
>  9.162 
> testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
> junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)
>  2.797 
> testJBossCmpJdbc Success  0.994 
> testWebXml Success  1.930 
> testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
> junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)
>  0.455 
> testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
> junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)
>  0.635 
> testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
> junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)
>  0.825 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:34:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4644) fix
 org.jboss.test.webservice.jbws309.JBWS309TestCase(JACC) - 5 errors
Message-ID: <9681728.1188322458268.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix org.jboss.test.webservice.jbws309.JBWS309TestCase(JACC) - 5 errors
----------------------------------------------------------------------

                 Key: JBAS-4644
                 URL: http://jira.jboss.com/jira/browse/JBAS-4644
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For:  JBossAS-5.0.0.Beta3


Problem appears either as:

testRoleSecuredServiceAccess Error Call invocation failed; nested exception is: java.io.IOException: Could not transmit message
java.rmi.RemoteException: Call invocation failed; nested exception is: 
	java.io.IOException: Could not transmit message
	at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:536)
	at org.jboss.ws.core.jaxrpc.client.CallImpl.invoke(CallImpl.java:277)
	at org.jboss.ws.core.jaxrpc.client.PortProxy.invoke(PortProxy.java:151)
	at $Proxy4.getContactInfo(Unknown Source)
	at org.jboss.test.webservice.jbws309.JBWS309TestCase.testRoleSecuredServiceAccess(JBWS309TestCase.java:190)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: java.io.IOException: Could not transmit message
	at org.jboss.ws.core.client.RemotingConnectionImpl.invoke(RemotingConnectionImpl.java:204)
	at org.jboss.ws.core.client.SOAPRemotingConnection.invoke(SOAPRemotingConnection.java:77)
	at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:337)
	at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:517)
	... 25 more
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:332)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:135)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
	at org.jboss.remoting.Client.invoke(Client.java:1550)
	at org.jboss.remoting.Client.invoke(Client.java:530)
	at org.jboss.ws.core.client.RemotingConnectionImpl.invoke(RemotingConnectionImpl.java:183)
	... 28 more
Caused by: org.jboss.ws.WSException: Invalid HTTP server response [401] - Unauthorized
	at org.jboss.ws.core.soap.SOAPMessageUnMarshaller.read(SOAPMessageUnMarshaller.java:77)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:472)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:304)
	... 33 more

Or

testRoleSecuredSLSB Error SecurityException; nested exception is: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
java.rmi.AccessException: SecurityException; nested exception is: 
	javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
	at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:388)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:136)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:640)
	at org.jboss.ejb.Container.invoke(Container.java:1006)
	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.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:230)
	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 javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
	at $Proxy14.invoke(Unknown Source)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
Caused by: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:212)
	at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:152)
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
	at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
	at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:524)
	at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:458)
	at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:353)
	at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:317)
	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:185)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invokeHome(PreSecurityInterceptor.java:140)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:640)
	at org.jboss.ejb.Container.invoke(Container.java:1006)
	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.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:230)
	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 javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
	at $Proxy14.invoke(Unknown Source)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
	at org.jboss.remoting.Client.invoke(Client.java:1550)
	at org.jboss.remoting.Client.invoke(Client.java:530)
	at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:161)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:244)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:181)
	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:86)
	at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
	at $Proxy1.create(Unknown Source)
	at org.jboss.test.webservice.jbws309.JBWS309TestCase.testRoleSecuredSLSB(JBWS309TestCase.java:93)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)

 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:40:20 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 15:40:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26805821.1188330020416.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana reassigned JBAS-4619:
-----------------------------------

    Assignee: Anil Saldhana  (was: Scott M Stark)

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:42:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 15:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9327541.1188330138474.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana updated JBAS-4619:
--------------------------------

    Fix Version/s: JBossAS-4.2.2.GA

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.2.2.GA
>
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:42:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 15:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30990735.1188330138751.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana updated JBAS-4619:
--------------------------------

    Affects Version/s: JBossAS-4.2.1.GA
                       JBossAS-4.2.0.GA

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.2.2.GA
>
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:47:23 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4645) Fix
 org.jboss.test.web.test.ClusteredSingleSignOnUnitTestCase
Message-ID: <20045340.1188330443085.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.web.test.ClusteredSingleSignOnUnitTestCase
-------------------------------------------------------------

                 Key: JBAS-4645
                 URL: http://jira.jboss.com/jira/browse/JBAS-4645
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:49:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
Message-ID: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
------------------------------------------------------------------------

                 Key: JBAS-4646
                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:51:21 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
In-Reply-To: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <445831.1188330681457.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry updated JBAS-4646:
-----------------------------------

    Fix Version/s: JBossAS-4.2.1.GA

This needs to be fixed for a release that can go in JBoss 5.

> Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4646
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.2.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 lists.jboss.org  Tue Aug 28 15:51:22 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:51:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
In-Reply-To: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19510261.1188330682670.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry updated JBAS-4646:
-----------------------------------

    Comment: was deleted

> Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4646
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.2.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 lists.jboss.org  Tue Aug 28 15:53:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
In-Reply-To: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19342089.1188330798318.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry updated JBAS-4646:
-----------------------------------

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

Editing wrong JIRA.

> Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4646
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:53:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1170) Partial state
 transfer fails when multiple regions present
In-Reply-To: <5358429.1187970318264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12060861.1188330798503.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1170?page=all ]

Brian Stansberry updated JBCACHE-1170:
--------------------------------------

    Fix Version/s: 2.1.0.GA

This needs to be fixed in time for a release to integrate in AS 5.0.0.CR1.

> Partial state transfer fails when multiple regions present
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1170
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1170
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  
> Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state
> The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all.
> Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:
> 1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.
> 2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should 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 lists.jboss.org  Tue Aug 28 16:16:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 16:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16618213.1188332178867.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374285 ] 
            
Alejandro Guizar commented on BPEL-277:
---------------------------------------

The representation of a part P1 defined with a type T is an element with a null namespace URI and a local name equal to the name of P1.
Conversely, the representation of a part P2 defined with an element E is an element with a qualified name equal to the qualified name of E.

Your query is written as if part "entrada" was defined with a type, hence the bpel:selectionFailure fault. Try this:

<copy>
       <from variable="nombres" />
       <to variable="entradaPruebaElectrica" part="entrada" query="/tns1:EE/usuario"/>
 </copy>

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 16:25:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 16:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22998788.1188332718262.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374287 ] 
            
Alejandro Guizar commented on BPEL-277:
---------------------------------------

Alternatively, if you have a BPEL 2 process, the location path can be relative:

<copy>
       <from variable="nombres" />
       <to variable="entradaPruebaElectrica" part="entrada" query="usuario"/>
 </copy>

In fact, in jBPM BPEL this works in BPEL 1.1 processes as well, but we do not recommend it because the specification mandates absolute location paths.

You can find examples of BPEL 2 processes created using the Eclipse BPEL designer in our CVS repository: http://fisheye.jboss.com/browse/JBPM/jbpm.3/bpel/examples
In each example process, look for subdirectory src/main/bpel2.

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 16:46:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1030) Updated JBM
 to use new patched JBoss remoting jar
In-Reply-To: <11490984.1186597669494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9961628.1188333978476.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic reassigned JBMESSAGING-1030:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Updated JBM to use new patched JBoss remoting jar
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1030
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1030
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Update JBM to use new patched jar which resolves all known remoting 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 lists.jboss.org  Tue Aug 28 16:46:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1030) Updated JBM to
 use new patched JBoss remoting jar
In-Reply-To: <11490984.1186597669494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13549267.1188333978726.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1030.
----------------------------------------

    Resolution: Done

> Updated JBM to use new patched JBoss remoting jar
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1030
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1030
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Update JBM to use new patched jar which resolves all known remoting 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 lists.jboss.org  Tue Aug 28 16:50:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
Message-ID: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>

Oracle Persistence hits a driver bug on binding blobs
-----------------------------------------------------

                 Key: JBMESSAGING-1060
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR2
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2


PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...

We will work around the 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 lists.jboss.org  Tue Aug 28 16:52:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32748280.1188334338504.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic updated JBMESSAGING-1060:
-----------------------------------------

    Priority: Blocker  (was: Major)

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Tue Aug 28 16:56:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14816021.1188334578266.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1060.
----------------------------------------

    Resolution: Done

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Tue Aug 28 17:08:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 17:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-411) Create basic pom
 structure for jbossas
Message-ID: <1158519.1188335298270.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create basic pom structure for jbossas
--------------------------------------

                 Key: JBBUILD-411
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-411
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
         Assigned To: Paul Gier
             Fix For: Maven Build - App Server


The first step in as mavenization should be to create basic poms with dependency listings in each module.
Also a parent pom should be created in the build directory, and possibly an aggregator pom in the root directory.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:10:21 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 17:10:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-258) Create functional
 pom for each module in head
Message-ID: <5720052.1188335421952.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-258?page=all ]

Paul Gier updated JBBUILD-258:
------------------------------

        Summary: Create functional pom for each module in head  (was: Create Pom file for each module in head)
    Description: A working pom should be created for each as module.  This means all main and test code compiles, tests run where applicable, and appropriate artifacts (jars, etc) are generated.  (was: Need to port the pom files from from the svn copy over to head.   Will need to update the pom's with recent changes made by developers.

(e.g. recent changes to webservice))

> Create functional pom for each module in head
> ---------------------------------------------
>
>                 Key: JBBUILD-258
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-258
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> A working pom should be created for each as module.  This means all main and test code compiles, tests run where applicable, and appropriate artifacts (jars, etc) are generated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:20:18 2007
From: jira-events at lists.jboss.org (Meriah Garrett (JIRA))
Date: Tue, 28 Aug 2007 17:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-235) Redesign LnF for
 SplitTopicView
In-Reply-To: <31523841.1179413935752.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2299880.1188336018915.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Meriah Garrett resolved JBFORUMS-235.
-------------------------------------

    Resolution: Done

> Redesign LnF for SplitTopicView 
> --------------------------------
>
>                 Key: JBFORUMS-235
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-235
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum View Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Meriah Garrett
>             Fix For: 1.0.1 RC
>
>
> Redesign the page view based on the new forums look and feel. Look for usability wins in the process.
> SplitTopicView available here : http://forums.proto.jboss.com:8080/portal/auth/portal/default/Forum/Forums?action=1&v=o&t=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 lists.jboss.org  Tue Aug 28 17:22:18 2007
From: jira-events at lists.jboss.org (Meriah Garrett (JIRA))
Date: Tue, 28 Aug 2007 17:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-229) Redesign LnF for
 Moderator Panel
In-Reply-To: <23022146.1178124330179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25473876.1188336138382.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Meriah Garrett resolved JBFORUMS-229.
-------------------------------------

    Fix Version/s:     (was: 1.0.1 RC)
       Resolution: Done

> Redesign LnF for Moderator Panel
> --------------------------------
>
>                 Key: JBFORUMS-229
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-229
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum View Layer
>            Reporter: James Cobb
>         Assigned To: Meriah Garrett
>
> Redesign the page view based on the new forums look and feel. Look for usability wins in the process. 
> Whole moderator panel is not rethemed. 
> You need to log in as admin/admin: 
> http://forums.proto.jboss.com:8080/portal/auth/portal/default/Forum/Forums?action=1&v=m&f=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 lists.jboss.org  Tue Aug 28 17:22:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 17:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1650) Add descriptions
 and unify Theme pages
Message-ID: <22204306.1188336138482.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add descriptions and unify Theme pages
--------------------------------------

                 Key: JBPORTAL-1650
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1650
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 28 17:24:34 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 28 Aug 2007 17:24:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
Message-ID: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>

Duplicate FixMe Class Entries In jar Table of Contents
------------------------------------------------------

                 Key: JBPORTAL-1651
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final
            Reporter: Mike Millson
         Assigned To: Julien Viet
            Priority: Minor


Running the following command shows 2 FixMe.class entries in the table of contents.
jar tf portal-common-lib.jar | grep FixMe

Creating an index (jar i portal-common-lib.jar) results in the following exception:
java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class

This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:26:25 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 17:26:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1650) Add descriptions
 and unify Theme pages
In-Reply-To: <22204306.1188336138482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16509006.1188336385099.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun updated JBPORTAL-1650:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final

> Add descriptions and unify Theme pages
> --------------------------------------
>
>                 Key: JBPORTAL-1650
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1650
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 17:26:25 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 28 Aug 2007 17:26:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20687125.1188336385755.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mike Millson updated JBPORTAL-1651:
-----------------------------------

    Attachment: patch.txt

Patch implementing duplicate="preserve" solution.

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Julien Viet
>            Priority: Minor
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:30:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 17:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27514694.1188336618472.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1651:
-----------------------------------

    Fix Version/s: 2.6.2 Final
         Assignee: Thomas Heute  (was: Julien Viet)

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:32:19 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 28 Aug 2007 17:32:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1651) Duplicate
 FixMe Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2452086.1188336739544.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=comments#action_12374305 ] 
            
Mike Millson commented on JBPORTAL-1651:
----------------------------------------

The following version of this jar in repository.jboss.com also has the duplicate FixMe class in the table of contents:
http://repository.jboss.com/jboss-portal/modules/common/1.0.0-SNAPSHOT/lib/portal-common-lib.jar

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:37:23 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 17:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17888277.1188337043364.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Anil Saldhana closed JBAS-4619.
-------------------------------

    Resolution: Done

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.2.2.GA
>
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:53:18 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 28 Aug 2007 17:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-387) Throw Exceptions when
 a valid advice is not found
In-Reply-To: <29000092.1176742620837.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7370692.1188337998857.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-387?page=all ]

Flavia Rainone closed JBAOP-387.
--------------------------------

    Resolution: Done

> Throw Exceptions when a valid advice is not found
> -------------------------------------------------
>
>                 Key: JBAOP-387
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-387
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Flavia Rainone
>             Fix For: 2.0.0.beta
>
>
> We need to throw an exception warning the user that a valid advice method couldn't be found for a specific joinpoint scenario. (currently, we are printing warnings in the org.jboss.aop.advice.annotation.AdviceMethodFactory algorithm).
> This task involves changes to org.jboss.aop.advice.PerVMAdvice and org.jboss.aop.advice.annotation.AdviceMethodFactory classes.
> We also need to update the documentation, telling when this runtime exception will be thrown.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:55:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 17:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7809877.1188338118835.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1651.
------------------------------------

    Resolution: Done

Will be correct in 2.6.2, thank you Mike !

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 18:01:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 18:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4641) Move
 XMLJUnitMultipleResultFormatter from testsuite module to test module
In-Reply-To: <184925.1188321258850.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24518379.1188338478219.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry closed JBAS-4641.
----------------------------------

    Resolution: Done

> Move XMLJUnitMultipleResultFormatter from testsuite module to test module
> -------------------------------------------------------------------------
>
>                 Key: JBAS-4641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.2.2.GA
>
>
> In Branch_4_2, this class is located in the testsuite module rather than in test.  In trunk it's in the jboss-test.jar, so logically it belongs in the test module in Branch_4_2.
> I need this class to get separate reports of the same EJB3 test under different configs (see EJBTHREE-856).  The EJB3 testsuite setup that tries to use the std ant XMLJUnitResultFormatter with different "extension" attribute values doesn't work.  I don't want to add the testsuite module to the junit task classpath in EJB3; that could have too many unintended side effects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 19:33:19 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 28 Aug 2007 19:33:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1651) Duplicate
 FixMe Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6212467.1188343999596.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=comments#action_12374324 ] 
            
Julien Viet commented on JBPORTAL-1651:
---------------------------------------

The generated jar in common is wrong it is missing some classes now and prevent other modules to be build or to link correctly. (like TransactionAssert)


> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 19:37:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 19:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-276) generate bpel
 application descriptor along with wsdl service description
In-Reply-To: <23516822.1187644158226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5203864.1188344238233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-276?page=all ]

Alejandro Guizar updated BPEL-276:
----------------------------------

    Description: 
PROBLEM The associations between the partner links and the published WSDL ports are declared in bpel-application.xml. 

In the provided examples, such associations can be inferred and are not present in the descriptor. This is because only one port in the WSDL document implements the port type associated with each partner link. In the general case, however, multiple ports may implement the same port type, making the association to partner links ambiguous.

During the procedure to generate a WSDL service description, the tool generates the WSDL port for each partner link and retains the unambiguous associations, but does not preserve them.

PROPOSAL Have the service description tool write the associations between partner links and WSDL ports to a generated bpel-application.xml file.

> generate bpel application descriptor along with wsdl service description
> ------------------------------------------------------------------------
>
>                 Key: BPEL-276
>                 URL: http://jira.jboss.com/jira/browse/BPEL-276
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The associations between the partner links and the published WSDL ports are declared in bpel-application.xml. 
> In the provided examples, such associations can be inferred and are not present in the descriptor. This is because only one port in the WSDL document implements the port type associated with each partner link. In the general case, however, multiple ports may implement the same port type, making the association to partner links ambiguous.
> During the procedure to generate a WSDL service description, the tool generates the WSDL port for each partner link and retains the unambiguous associations, but does not preserve them.
> PROPOSAL Have the service description tool write the associations between partner links and WSDL ports to a generated bpel-application.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 lists.jboss.org  Tue Aug 28 19:41:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1644) Add Default
 status / Make Default action to object (e.g. portal, page) tables
In-Reply-To: <4492260.1187722530673.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9351632.1188344478538.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun resolved JBPORTAL-1644.
------------------------------------

    Resolution: Done

> Add Default status / Make Default action to object (e.g. portal, page) tables
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1644
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1644
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 19:45:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1650) Add
 descriptions and unify Theme pages
In-Reply-To: <22204306.1188336138482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4717266.1188344718220.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun resolved JBPORTAL-1650.
------------------------------------

    Resolution: Done

> Add descriptions and unify Theme pages
> --------------------------------------
>
>                 Key: JBPORTAL-1650
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1650
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 19:51:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1652) Unify "create"
 button text in Create New * forms
Message-ID: <1889953.1188345078189.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unify "create" button text in Create New * forms
------------------------------------------------

                 Key: JBPORTAL-1652
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1652
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 28 19:53:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1652) Unify "create"
 button text in Create New * forms
In-Reply-To: <1889953.1188345078189.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22395266.1188345198176.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Chris Laprun updated JBPORTAL-1652:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final

> Unify "create" button text in Create New * forms
> ------------------------------------------------
>
>                 Key: JBPORTAL-1652
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1652
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 20:19:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Tue, 28 Aug 2007 20:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10284515.1188346758346.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

William DeCoste reassigned EJBTHREE-1033:
-----------------------------------------

    Assignee: William DeCoste  (was: Carlo de Wolf)

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 21:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 21:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29496315.1188350658342.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic reassigned JBMESSAGING-1026:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Ensure successfull test run against all supported databases
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Postgresql, MySQL, Sybase, Oracle, MSSQL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 21:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 21:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1048) Test DB2
 config against Hudson
In-Reply-To: <16680822.1187133001211.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28348628.1188350658546.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1048?page=comments#action_12374331 ] 
            
Clebert Suconic commented on JBMESSAGING-1048:
----------------------------------------------

Here is some useful doc
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0sttmsg.htm

> Test DB2 config against Hudson
> ------------------------------
>
>                 Key: JBMESSAGING-1048
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1048
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 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 lists.jboss.org  Tue Aug 28 21:31:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 21:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30057349.1188351078294.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Clebert Suconic closed JBMESSAGING-1026.
----------------------------------------

    Resolution: Done

> Ensure successfull test run against all supported databases
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Postgresql, MySQL, Sybase, Oracle, MSSQL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 22:51:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 22:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1651) Duplicate
 FixMe Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30538916.1188355878353.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=comments#action_12374334 ] 
            
Thomas Heute commented on JBPORTAL-1651:
----------------------------------------

Then there is a packaging issue:

I changed this:
	      <jar jarfile="${build.lib}/portal-common-lib.jar" manifest="${build.etc}/portal-common-lib-jar.mf">
                <fileset dir="${build.classes}"/>
	         <fileset dir="${build.resources}/format/code"/>
               <fileset dir="${build.classes}">
                <exclude name="org/jboss/portal/common/ant/**/*"/>
                <exclude name="org/jboss/portal/common/junit/**/*"/>
             </fileset>
	      </jar>

to this:
	      <jar jarfile="${build.lib}/portal-common-lib.jar" manifest="${build.etc}/portal-common-lib-jar.mf">
	         <fileset dir="${build.resources}/format/code"/>
             <fileset dir="${build.classes}">
                <exclude name="org/jboss/portal/common/ant/**/*"/>
                <exclude name="org/jboss/portal/common/junit/**/*"/>
             </fileset>
	      </jar>

ant and junit packages being in explode.jar.

I'll check on that

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 22:51:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 22:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20978742.1188355878492.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute reopened JBPORTAL-1651:
------------------------------------

             

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 22:53:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 22:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1360855.1188355998328.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1651.
------------------------------------

    Resolution: Done

oups you fixed this already.

Thanks and sorry

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 23:20:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 23:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-276) generate bpel
 application descriptor along with wsdl service description
In-Reply-To: <23516822.1187644158226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22934969.1188357618209.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-276?page=all ]

Alejandro Guizar resolved BPEL-276.
-----------------------------------

    Resolution: Done

SOLUTION Modified the wsdl service generation tool to produce an application descriptor object. Introduced a descriptor writer that transforms the descriptor object into a DOM tree which is later saved as XML.

> generate bpel application descriptor along with wsdl service description
> ------------------------------------------------------------------------
>
>                 Key: BPEL-276
>                 URL: http://jira.jboss.com/jira/browse/BPEL-276
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The associations between the partner links and the published WSDL ports are declared in bpel-application.xml. 
> In the provided examples, such associations can be inferred and are not present in the descriptor. This is because only one port in the WSDL document implements the port type associated with each partner link. In the general case, however, multiple ports may implement the same port type, making the association to partner links ambiguous.
> During the procedure to generate a WSDL service description, the tool generates the WSDL port for each partner link and retains the unambiguous associations, but does not preserve them.
> PROPOSAL Have the service description tool write the associations between partner links and WSDL ports to a generated bpel-application.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 lists.jboss.org  Wed Aug 29 03:13:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 29 Aug 2007 03:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-797)
 BisocketClientInvoker.PingTimerTask should terminate more gracefully
Message-ID: <5016115.1188371598220.JavaMail.jira@cloud.prod.atl2.jboss.com>

BisocketClientInvoker.PingTimerTask should terminate more gracefully
--------------------------------------------------------------------

                 Key: JBREM-797
                 URL: http://jira.jboss.com/jira/browse/JBREM-797
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.2.GA
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
            Priority: Minor
             Fix For: 2.4.0.Beta1 (Pinto)


If org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask is running when PingTimerTask.shutDown() is called, it might get an exception trying to send a ping.  However, there is no reason to log a warning.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 03:19:37 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 29 Aug 2007 03:19:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-584) Reconnection with TCP
 might not work well
Message-ID: <19639183.1188371977487.JavaMail.jira@cloud.prod.atl2.jboss.com>

Reconnection with TCP might not work well
-----------------------------------------

                 Key: JGRP-584
                 URL: http://jira.jboss.com/jira/browse/JGRP-584
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


If we use TCP, then a shun followed by an automatic reconnect may not work, as the reconnect will fail to join due to the reincarnation issue (http://jira.jboss.com/jira/browse/JGRP-130).
Investigate whether this works. If it doesn't work, we can possibly run the reconnect in a loop until the rejoin is successful, or until the channel is closed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 03:41:47 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Wed, 29 Aug 2007 03:41:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27475250.1188373307345.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12374367 ] 
            
Andrew Rubinger commented on EJBTHREE-1025:
-------------------------------------------

Tests merged to trunk in 64940, fix in 64941.

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Andrew Rubinger
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 04:48:25 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 04:48:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1564) Review Event
	chapter (IPC)
In-Reply-To: <30907420.1184080660159.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32728378.1188377305348.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1564.
------------------------------------

    Resolution: Done

> Review Event chapter (IPC)
> --------------------------
>
>                 Key: JBPORTAL-1564
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1564
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> The event chapter is missing info about jboss-config.xml and -object to write.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 04:58:28 2007
From: jira-events at lists.jboss.org (Felipe Jensen Casado (JIRA))
Date: Wed, 29 Aug 2007 04:58:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23381026.1188377908951.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374374 ] 
            
Felipe Jensen Casado commented on BPEL-277:
-------------------------------------------

My process is 1.1 and you are totally right, Alejandro: It works perfectly, sorry. I had also tried using a qname, but my mistake was writing the name of the part in the query, instead of the name of the xsd element.

Thanks for the help and so this is closed.
Greetings.

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 05:09:37 2007
From: jira-events at lists.jboss.org (Felipe Jensen Casado (JIRA))
Date: Wed, 29 Aug 2007 05:09:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31005845.1188378577525.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374375 ] 
            
Felipe Jensen Casado commented on BPEL-277:
-------------------------------------------

And thanks also for the specification of the representation of parts. I haven't found anything about it in the wsdl nor the bpel 1.1 specifications.

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 05:21:27 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 05:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1580) [PATCH] updated
 helloworld jsf portlet
In-Reply-To: <8511276.1184442783989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <400809.1188379287519.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute resolved JBPORTAL-1580.
------------------------------------

    Resolution: Done

> [PATCH] updated helloworld jsf portlet
> --------------------------------------
>
>                 Key: JBPORTAL-1580
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1580
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Samples
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: helloworldportlet.zip
>
>
> I also uploaded this to portalswap but I'm not sure it is being monitored.  This is an updated version of the helloworldjsf that works on JBP 2.6+JBAS 4.2.  The previous one that was there did NOT work on the 2.6/4.2 combo.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 06:21:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 29 Aug 2007 06:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4647) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.CR1
Message-ID: <8465370.1188382878491.JavaMail.jira@cloud.prod.atl2.jboss.com>

Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.CR1
--------------------------------------------------------------------

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


Create subtasks to track jboss and thirdparty 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 lists.jboss.org  Wed Aug 29 06:21:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 29 Aug 2007 06:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4648) Upgrade jboss
 transactions to 4.4 (from 4.3)
Message-ID: <10620822.1188382878617.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss transactions to 4.4 (from 4.3)
--------------------------------------------

                 Key: JBAS-4648
                 URL: http://jira.jboss.com/jira/browse/JBAS-4648
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 06:23:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 29 Aug 2007 06:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4648) Upgrade jboss
 transactions to 4.4 (from 4.3)
In-Reply-To: <10620822.1188382878617.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31994488.1188382998387.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Dimitris Andreadis reassigned JBAS-4648:
----------------------------------------

    Assignee: Jonathan Halliday

> Upgrade jboss transactions to 4.4 (from 4.3)
> --------------------------------------------
>
>                 Key: JBAS-4648
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4648
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Jonathan Halliday
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 06:34:18 2007
From: jira-events at lists.jboss.org (Michal Borowiecki (JIRA))
Date: Wed, 29 Aug 2007 06:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-91) AJP implementation
 broken :
 ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
Message-ID: <6742831.1188383658382.JavaMail.jira@cloud.prod.atl2.jboss.com>

AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
------------------------------------------------------------------------------------------------

                 Key: JBWEB-91
                 URL: http://jira.jboss.com/jira/browse/JBWEB-91
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Linux 2.6.20-gentoo-r8 #1 SMP
jbossweb-1.0.1.GA-linux2-i686.tar.gz
sun-jdk-1.5.0.11 and sun-jdk-1.6.0.01
Apache: Apache/1.3.37
JK: mod_jk/1.2.18
            Reporter: Michal Borowiecki
         Assigned To: Mladen Turk
             Fix For:  JBoss Web Server 1.0.1 GA


When response is greater than abount 225 kB and error is detected on Apache side in mod_jK:

last normal log entry:
[Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for

then error:
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed

At another time the error message said:
[Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
or
[Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c

JBoss logs show a normal response sent: 
[29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
[29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579

Apache logs show an error:
[29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
[29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265

The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 06:48:18 2007
From: jira-events at lists.jboss.org (Michal Borowiecki (JIRA))
Date: Wed, 29 Aug 2007 06:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-91) AJP implementation
 broken :
 ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
In-Reply-To: <6742831.1188383658382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14156851.1188384498262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-91?page=all ]

Michal Borowiecki updated JBWEB-91:
-----------------------------------

    Description: 
When response is greater than about 225 kB an error is detected on Apache side in mod_jK:

last normal log entry:
[Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for

then error:
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed

At another time the error message said:
[Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
or
[Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c

JBoss logs show a normal response sent: 
[29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
[29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579

Apache logs show an error:
[29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
[29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265

The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

  was:
When response is greater than abount 225 kB and error is detected on Apache side in mod_jK:

last normal log entry:
[Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for

then error:
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed

At another time the error message said:
[Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
or
[Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c

JBoss logs show a normal response sent: 
[29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
[29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579

Apache logs show an error:
[29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
[29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265

The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.


fixed typoos

> AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-91
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-91
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Linux 2.6.20-gentoo-r8 #1 SMP
> jbossweb-1.0.1.GA-linux2-i686.tar.gz
> sun-jdk-1.5.0.11 and sun-jdk-1.6.0.01
> Apache: Apache/1.3.37
> JK: mod_jk/1.2.18
>            Reporter: Michal Borowiecki
>         Assigned To: Mladen Turk
>             Fix For:  JBoss Web Server 1.0.1 GA
>
>
> When response is greater than about 225 kB an error is detected on Apache side in mod_jK:
> last normal log entry:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for
> then error:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed
> At another time the error message said:
> [Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
> or
> [Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c
> JBoss logs show a normal response sent: 
> [29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
> [29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579
> Apache logs show an error:
> [29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
> [29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265
> The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 07:03:18 2007
From: jira-events at lists.jboss.org (Michal Borowiecki (JIRA))
Date: Wed, 29 Aug 2007 07:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-91) AJP implementation
 broken :
 ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
In-Reply-To: <6742831.1188383658382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20267897.1188385398288.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-91?page=comments#action_12374382 ] 
            
Michal Borowiecki commented on JBWEB-91:
----------------------------------------

Serving the same JPS page/ static file works fine when using the HTTP connector.
The problem only affects the AJP connector.

> AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-91
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-91
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Linux 2.6.20-gentoo-r8 #1 SMP
> jbossweb-1.0.1.GA-linux2-i686.tar.gz
> sun-jdk-1.5.0.11 and sun-jdk-1.6.0.01
> Apache: Apache/1.3.37
> JK: mod_jk/1.2.18
>            Reporter: Michal Borowiecki
>         Assigned To: Mladen Turk
>             Fix For:  JBoss Web Server 1.0.1 GA
>
>
> When response is greater than about 225 kB an error is detected on Apache side in mod_jK:
> last normal log entry:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for
> then error:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed
> At another time the error message said:
> [Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
> or
> [Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c
> JBoss logs show a normal response sent: 
> [29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
> [29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579
> Apache logs show an error:
> [29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
> [29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265
> The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:22:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 09:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-856) Use Buddy
 Replication for clustered SFSBs
In-Reply-To: <24225310.1170195680226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22026767.1188393738856.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry updated EJBTHREE-856:
--------------------------------------

    Fix Version/s: AS 4.2.2.GA

> Use Buddy Replication for clustered SFSBs
> -----------------------------------------
>
>                 Key: EJBTHREE-856
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-856
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> Optimize the replicated SFSB cache for use with Buddy Replication.  Basically means checking cache calls to ensure unwanted data gravitations do not 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 lists.jboss.org  Wed Aug 29 09:29:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 09:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4649) Upgrade to JBoss
	Cache 1.4.1.SP4
Message-ID: <6760331.1188394158264.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade to JBoss Cache 1.4.1.SP4
--------------------------------

                 Key: JBAS-4649
                 URL: http://jira.jboss.com/jira/browse/JBAS-4649
             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.2.2.GA


>From 1.4.1.SP3.  Needed for EJBTHREE-856.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:36:13 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 09:36:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4649) Upgrade to JBoss
	Cache 1.4.1.SP4
In-Reply-To: <6760331.1188394158264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19033459.1188394573078.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Brian Stansberry closed JBAS-4649.
----------------------------------

    Resolution: Done

> Upgrade to JBoss Cache 1.4.1.SP4
> --------------------------------
>
>                 Key: JBAS-4649
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4649
>             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.2.2.GA
>
>
> From 1.4.1.SP3.  Needed for EJBTHREE-856.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:41:18 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Aug 2007 09:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4650)
 JSFIntegrationUnitTestCase is failing for JBoss AS 5
Message-ID: <20338587.1188394878196.JavaMail.jira@cloud.prod.atl2.jboss.com>

JSFIntegrationUnitTestCase is failing for JBoss AS 5
----------------------------------------------------

                 Key: JBAS-4650
                 URL: http://jira.jboss.com/jira/browse/JBAS-4650
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Stan Silvert
         Assigned To: Stan Silvert
             Fix For: JBossAS-5.0.0.GA


JSFIntegrationUnitTestCase fails.  The specific assertion that fails is in the logging test.  This was caused by setting a default logging level for JSF in log4j.xml.

If you run the test twice, it will pass the second time because the test sets logging levels by hitting the Log4JService via HTTP.  However, because the WAR for the test is deployed before the logging levels were changed, the WAR would be deployed with the old logging values.  So the fix is to change the test to set the logging levels before the WAR 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 lists.jboss.org  Wed Aug 29 09:43:18 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Aug 2007 09:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4650)
 JSFIntegrationUnitTestCase is failing for JBoss AS 5
In-Reply-To: <20338587.1188394878196.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28751627.1188394998214.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Stan Silvert resolved JBAS-4650.
--------------------------------

    Resolution: Done

Fixed

> JSFIntegrationUnitTestCase is failing for JBoss AS 5
> ----------------------------------------------------
>
>                 Key: JBAS-4650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4650
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>             Fix For: JBossAS-5.0.0.GA
>
>
> JSFIntegrationUnitTestCase fails.  The specific assertion that fails is in the logging test.  This was caused by setting a default logging level for JSF in log4j.xml.
> If you run the test twice, it will pass the second time because the test sets logging levels by hitting the Log4JService via HTTP.  However, because the WAR for the test is deployed before the logging levels were changed, the WAR would be deployed with the old logging values.  So the fix is to change the test to set the logging levels before the WAR 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 lists.jboss.org  Wed Aug 29 09:50:18 2007
From: jira-events at lists.jboss.org (Andrew Oliver (JIRA))
Date: Wed, 29 Aug 2007 09:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1653) WSRP descriptor
	is invalid
Message-ID: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP descriptor is invalid
--------------------------

                 Key: JBPORTAL-1653
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
    Affects Versions: 2.6.1 Final, 2.6 Final
            Reporter: Andrew Oliver
         Assigned To: Julien Viet


ref guid has:

<!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
   "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
<?xml version="1.0" standalone="yes"?>
<deployments>
  <deployment>
    <wsrp-producer id="bea" expiration-cache="120">
      <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
      <registration-data>
        <property>
          <name>registration/consumerRole</name>
          <lang>en</lang>
          <value>public</value>
      </registration-data>
    </wsrp-producer>
  </deployment>
</deployments>

should read:
<?xml version="1.0"?>
<!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
   "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
<deployments>
  <deployment>
    <wsrp-producer id="bea" expiration-cache="120">
      <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
      <registration-data>
        <property>
          <name>registration/consumerRole</name>
          <lang>en</lang>
          <value>public</value>
        </property>
      </registration-data>
    </wsrp-producer>
  </deployment>
</deployments>

(the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:57:30 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 09:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1653) WSRP descriptor
	is invalid
In-Reply-To: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24981572.1188395850060.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Thomas Heute updated JBPORTAL-1653:
-----------------------------------

    Fix Version/s: 2.6.2 Final
         Assignee: Chris Laprun  (was: Julien Viet)

> WSRP descriptor is invalid
> --------------------------
>
>                 Key: JBPORTAL-1653
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Andrew Oliver
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final
>
>
> ref guid has:
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <?xml version="1.0" standalone="yes"?>
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> should read:
> <?xml version="1.0"?>
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>         </property>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> (the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:05:18 2007
From: jira-events at lists.jboss.org (Terry McKee (JIRA))
Date: Wed, 29 Aug 2007 10:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31879806.1188396318873.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374400 ] 
            
Terry McKee commented on JBAS-4491:
-----------------------------------

I also ran into this issue when trying to start the default configuration for JBoss 5.0.0.Beta2 with JDK 6.0.02.  No apps were deployed.  The server starts up correctly when I switch the JDK to version 5.0.12.

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Wed Aug 29 10:09:19 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Aug 2007 10:09:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4651) myfaces and
 commons-el should only be referenced by test suite
Message-ID: <29002583.1188396559360.JavaMail.jira@cloud.prod.atl2.jboss.com>

myfaces and commons-el should only be referenced by test suite
--------------------------------------------------------------

                 Key: JBAS-4651
                 URL: http://jira.jboss.com/jira/browse/JBAS-4651
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Stan Silvert
         Assigned To: Stan Silvert


The myfaces jar and the commons-el jar are only used by the test suite.  Right now they are referenced in build-thirdparty.xml in the full build.  We need to figure out if these jars can be referenced by the test suite 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 lists.jboss.org  Wed Aug 29 10:19:43 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Wed, 29 Aug 2007 10:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29498077.1188397183376.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Andrew Rubinger resolved EJBTHREE-1025.
---------------------------------------

    Resolution: Done

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Andrew Rubinger
>             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:47:19 2007
From: jira-events at lists.jboss.org (Andrew Oliver (JIRA))
Date: Wed, 29 Aug 2007 10:47:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1653) WSRP
	descriptor is invalid
In-Reply-To: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32592087.1188398839117.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1653?page=comments#action_12374408 ] 
            
Andrew Oliver commented on JBPORTAL-1653:
-----------------------------------------

check it over, jira munged the cut and paste

> WSRP descriptor is invalid
> --------------------------
>
>                 Key: JBPORTAL-1653
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Andrew Oliver
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final
>
>
> ref guid has:
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <?xml version="1.0" standalone="yes"?>
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> should read:
> <?xml version="1.0"?>
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>         </property>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> (the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:54:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 10:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-931) Have defect with
 JavaBeans as fact.
In-Reply-To: <12767206.1182161952049.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12296788.1188399258277.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Try latest trunk and do read he discussions in the mailing list archive on this topic with other similar systems. The issue is often relate to the code generation framework marking classes and/or methods final, including equals and hashcode, which stops those classes working as expected in Drools.
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules

> Have defect with JavaBeans as fact.
> -----------------------------------
>
>                 Key: JBRULES-931
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-931
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.6
>         Environment: W-XP SP2
>            Reporter: Anthony Tran
>         Assigned To: Mark Proctor
>             Fix For: 3.0.6
>
>
> I use XMLBeans to generate and compile Java classes at runtime, then parse XML files to be objects of classess which has been compiled. Those objects are added into working memory as facts in my application. JBOSS Rule engine can recognize those facts, but can't bound. 
> Ex: 
> rule
>   when
>     p:ProductService(type == "monitor")
>     u:User(product == p)
>   then
>     .....
> end
> The LHS is never fired.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:56:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 10:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7242950.1188399378506.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

Mark Proctor updated JBRULES-1136:
----------------------------------

    Fix Version/s: 4.0.1

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 11:01:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 11:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1142) nested accessors
 on the lhs of
 the memberOf (or not memberOf) operator lead to an exception
In-Reply-To: <33222909.1188302555335.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14364584.1188399678677.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1142?page=all ]

Edson Tirelli closed JBRULES-1142.
----------------------------------

    Fix Version/s: 4.0.1
       Resolution: Duplicate Issue

http://jira.jboss.org/jira/browse/JBRULES-1089

> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception
> -------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1142
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1142
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.5, Drools 4.0.0.GA
>            Reporter: andreas kinell
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>   Original Estimate: 5 hours
>  Remaining Estimate: 5 hours
>
> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception:
> business logic (pseudocode):
> class Position {
>    private Instrument instrument;
> }
> class Instrument {
>    private Currency currency;
> }
> with getters and setters.
> rule:
> $collection : Collection()
> $position : Position(instrument.currency not memberOf $collection)
> exception:
> org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 1f99eea
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:212)
> 	at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:110)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:119)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at test.RuleTest.testRuleEngine1(RuleTest.java:99)
> Caused by: java.lang.ClassCastException: test.Currency
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36)
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:206)
> 	... 33 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 lists.jboss.org  Wed Aug 29 11:03:32 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 11:03:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1052) When running
 stress tests wrong log4j.xml is picked up
In-Reply-To: <10580807.1187882838240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16684303.1188399812419.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1052?page=all ]

Clebert Suconic closed JBMESSAGING-1052.
----------------------------------------

    Resolution: Done

Stress tests were picking the right one, but DEBUG became too verbose, so I'm setting thresholds to INFO

> When running stress tests wrong log4j.xml is picked up
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1052
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1052
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> When running stress tests, the log4j.xml from tests/etc, but the log4j.xml from tests/etc/stress isn't being used.
> This means stress tests are being run on trace logging, which is incorrect (makes them take ages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 11:05:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 11:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7045900.1188399918694.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1060?page=all ]

Clebert Suconic reopened JBMESSAGING-1060:
------------------------------------------

             

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Wed Aug 29 11:09:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 11:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7634891.1188400158271.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1060?page=all ]

Clebert Suconic closed JBMESSAGING-1060.
----------------------------------------

    Resolution: Done

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Wed Aug 29 11:51:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 11:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1600) inherit
 security constraint between portal Template and dashboards
In-Reply-To: <17178120.1184859228977.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28348776.1188402678678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1600?page=all ]

Thomas Heute resolved JBPORTAL-1600.
------------------------------------

    Resolution: Done

The way it is done is that only viewable objects are copied now. It should solve your use-case

> inherit security constraint between portal Template and dashboards
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1600
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1600
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Lionel ROSIER
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> we can apply security settings on the template portal, particularly  on the pages.
> but the security constraints are not inherit from the portal Template to the dashboards.
> a page which is secured with a role in the portal template is visible by every users in their dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 11:53:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 11:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1600) Dashboard also
 includes protected resources from 'template' on creation
In-Reply-To: <17178120.1184859228977.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10662037.1188402798262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1600?page=all ]

Thomas Heute updated JBPORTAL-1600:
-----------------------------------

    Summary: Dashboard also includes protected resources from 'template' on creation  (was: inherit security constraint between portal Template and dashboards)

Thanks for the report !

> Dashboard also includes protected resources from 'template' on creation
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1600
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1600
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Lionel ROSIER
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> we can apply security settings on the template portal, particularly  on the pages.
> but the security constraints are not inherit from the portal Template to the dashboards.
> a page which is secured with a role in the portal template is visible by every users in their dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 12:13:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 12:13:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1061) Failure on
 ClusteredPostOfficeTest
Message-ID: <23025559.1188403999391.JavaMail.jira@cloud.prod.atl2.jboss.com>

Failure on ClusteredPostOfficeTest
----------------------------------

                 Key: JBMESSAGING-1061
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1061
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR2
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2


Vladmir Blagojevic provided me this input about the ClusteredPostOfficeTest failures (related to the JGropus usage):

I have a workaround for you. I will continue to look for 100% solution in the coming days. What you have to do is introduce Thread.sleep(1000); at the end of GroupMember#stop() method. This gives a change to channels to cleanup properly. We get those errors from previous email when we rapidly shutdown bunch of channels.

After this change, specific test passes 100% and I get five failures and one error for the entire test. I get a lot of these:
  [junit] @main 10:20:48,203 WARN  [ProxyAssertSupport] AssertionFailure::junit.framework.AssertionFailedError
  [junit] junit.framework.AssertionFailedError
  [junit]     at junit.framework.Assert.fail(Assert.java:47)
  [junit]     at junit.framework.Assert.assertTrue(Assert.java:20)
  [junit]     at junit.framework.Assert.assertTrue(Assert.java:27)
  [junit]     at org.jboss.test.messaging.util.ProxyAssertSupport.assertTrue(ProxyAssertSupport.java:61)
  [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.clusteredRouteFourNodes(ClusteredPostOfficeTest.java:2140)
  [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.testClusteredRouteFourNodesNonPersistent(ClusteredPostOfficeTest.java:1374)
  [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  [junit]     at java.lang.reflect.Method.invoke(Method.java:585)
  [junit]     at junit.framework.TestCase.runTest(TestCase.java:164)
  [junit]     at junit.framework.TestCase.runBare(TestCase.java:130)
  [junit]     at junit.framework.TestResult$1.protect(TestResult.java:106)
  [junit]     at junit.framework.TestResult.runProtected(TestResult.java:124)
  [junit]     at junit.framework.TestResult.run(TestResult.java:109)
  [junit]     at junit.framework.TestCase.run(TestCase.java:120)
  [junit]     at junit.framework.TestSuite.runTest(TestSuite.java:230)
  [junit]     at junit.framework.TestSuite.run(TestSuite.java:225)
  [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
  [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
  [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)


but these seem to be related to message references. I tried changing these tests to use equals method rather than == and they started passing.
Not sure what are these about. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 12:15:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 12:15:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1061) Failure on
 ClusteredPostOfficeTest
In-Reply-To: <23025559.1188403999391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26146099.1188404119735.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1061?page=all ]

Clebert Suconic closed JBMESSAGING-1061.
----------------------------------------

    Resolution: Done

> Failure on ClusteredPostOfficeTest
> ----------------------------------
>
>                 Key: JBMESSAGING-1061
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1061
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Vladmir Blagojevic provided me this input about the ClusteredPostOfficeTest failures (related to the JGropus usage):
> I have a workaround for you. I will continue to look for 100% solution in the coming days. What you have to do is introduce Thread.sleep(1000); at the end of GroupMember#stop() method. This gives a change to channels to cleanup properly. We get those errors from previous email when we rapidly shutdown bunch of channels.
> After this change, specific test passes 100% and I get five failures and one error for the entire test. I get a lot of these:
>   [junit] @main 10:20:48,203 WARN  [ProxyAssertSupport] AssertionFailure::junit.framework.AssertionFailedError
>   [junit] junit.framework.AssertionFailedError
>   [junit]     at junit.framework.Assert.fail(Assert.java:47)
>   [junit]     at junit.framework.Assert.assertTrue(Assert.java:20)
>   [junit]     at junit.framework.Assert.assertTrue(Assert.java:27)
>   [junit]     at org.jboss.test.messaging.util.ProxyAssertSupport.assertTrue(ProxyAssertSupport.java:61)
>   [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.clusteredRouteFourNodes(ClusteredPostOfficeTest.java:2140)
>   [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.testClusteredRouteFourNodesNonPersistent(ClusteredPostOfficeTest.java:1374)
>   [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   [junit]     at java.lang.reflect.Method.invoke(Method.java:585)
>   [junit]     at junit.framework.TestCase.runTest(TestCase.java:164)
>   [junit]     at junit.framework.TestCase.runBare(TestCase.java:130)
>   [junit]     at junit.framework.TestResult$1.protect(TestResult.java:106)
>   [junit]     at junit.framework.TestResult.runProtected(TestResult.java:124)
>   [junit]     at junit.framework.TestResult.run(TestResult.java:109)
>   [junit]     at junit.framework.TestCase.run(TestCase.java:120)
>   [junit]     at junit.framework.TestSuite.runTest(TestSuite.java:230)
>   [junit]     at junit.framework.TestSuite.run(TestSuite.java:225)
>   [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
>   [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
>   [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)
> but these seem to be related to message references. I tried changing these tests to use equals method rather than == and they started passing.
> Not sure what are these about. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 12:50:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 12:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1013) Run clustered
 session tests with buddy replication enabled and disabled
In-Reply-To: <14148841.1184355843699.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30583606.1188406218386.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1013?page=all ]

Brian Stansberry closed EJBTHREE-1013.
--------------------------------------

    Fix Version/s: AS 4.2.2.GA
       Resolution: Done

> Run clustered session tests with buddy replication enabled and disabled
> -----------------------------------------------------------------------
>
>                 Key: EJBTHREE-1013
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1013
>             Project: EJB 3.0
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD
>
>
> For trunk, enabled will be the default, so need to setup tests to run with BR 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 lists.jboss.org  Wed Aug 29 12:58:18 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Wed, 29 Aug 2007 12:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2603318.1188406698323.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374436 ] 
            
Remy Maucherat commented on JBAS-4562:
--------------------------------------

Ideally, I would like to integrate a CR release of JBoss Web 2.1 in the beta 3 build. This should not be an issue, but there will be a small update needed since this new version slightly updates the annotation integration interface. Would this be acceptable, or would you prefer sticking with a JBoss Web 2.0.1 GA and upgrading post beta 3  ?

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 13:26:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 13:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1653) WSRP descriptor
	is invalid
In-Reply-To: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20752555.1188408378297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1653?page=all ]

Chris Laprun resolved JBPORTAL-1653.
------------------------------------

    Fix Version/s: 2.8 Final
       Resolution: Done

> WSRP descriptor is invalid
> --------------------------
>
>                 Key: JBPORTAL-1653
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Andrew Oliver
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> ref guid has:
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <?xml version="1.0" standalone="yes"?>
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> should read:
> <?xml version="1.0"?>
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>         </property>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> (the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 14:03:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1652) Unify "create"
 button text in Create New * forms
In-Reply-To: <1889953.1188345078189.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10618754.1188410598407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1652?page=all ]

Chris Laprun resolved JBPORTAL-1652.
------------------------------------

    Resolution: Done

> Unify "create" button text in Create New * forms
> ------------------------------------------------
>
>                 Key: JBPORTAL-1652
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1652
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Wed Aug 29 14:07:19 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:07:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1654) Add separators
 on object
 pages to allow for better distinction between object and children
 operations
Message-ID: <20695198.1188410839568.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add separators on object pages to allow for better distinction between object and children operations
-----------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1654
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1654
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Wed Aug 29 14:11:32 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:11:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1655) Improve "rename"
	forms
Message-ID: <2649337.1188411092173.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve "rename" forms
----------------------

                 Key: JBPORTAL-1655
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1655
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Wed Aug 29 14:13:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1656) NPE when trying
 to delete an
 object in the admin portlet and cancelling the operation by pressing No in
 the confirmation dialog
Message-ID: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
-------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1656
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.2 Final, 2.8 Final


java.lang.NullPointerException
	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 14:15:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1657) Improve confirm
 deletion pages
Message-ID: <30785252.1188411318174.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve confirm deletion pages
------------------------------

                 Key: JBPORTAL-1657
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1657
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Wed Aug 29 14:33:29 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 14:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29504361.1188412409734.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=comments#action_12374456 ] 
            
Edson Tirelli commented on JBRULES-1131:
----------------------------------------

Added a getErrorLines() method to all DroolsError classes... need to integrate that into the engine and maybe do some improvements, as required.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Wed Aug 29 14:58:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 14:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19994790.1188413898311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=all ]

Edson Tirelli closed JBRULES-1131.
----------------------------------

    Resolution: Done

Fixed.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Wed Aug 29 16:55:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-8) Handling of (state)
 merging --> emission of callbacks/notifications
Message-ID: <13542193.1188420918746.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-8?page=all ]

Brian Stansberry updated JBCACHE-8:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

Added link to forum post.  I'm now doubting this is doable for 2.1. :(

> Handling of (state) merging --> emission of callbacks/notifications
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-8
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-8
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2.4SP1, 1.2.4, 1.2.4beta, 1.2.3, 1.2.2, 1.2.1, 1.2, 1.3.0.SP2, 1.3.0.SP1, 1.3.0.GA
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We need to look into handling the merge for JBossCache. Merging occurs after a network partition, or as result of 2 members starting concurrently, or as a result of a PING.timeout set too low

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:57:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4224) Handle merging of
 distributed session state if a MergeView is received
In-Reply-To: <23411494.1174424269688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6940985.1188421038300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4224?page=all ]

Brian Stansberry updated JBAS-4224:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handle merging of distributed session state if a MergeView is received
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4224
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4224
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs.  Need to work with the JBC team to design the callback and to implement a solution that will allow merging of web sessions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:57:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4223) Handle merging of
 ClusterPartition state if MergeView is received
In-Reply-To: <16889233.1174424148883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31477813.1188421038417.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4223?page=all ]

Brian Stansberry updated JBAS-4223:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handle merging of ClusterPartition state if MergeView is received
> -----------------------------------------------------------------
>
>                 Key: JBAS-4223
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4223
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 16:59:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-922) Handle merging of
 clustered SFSB state if a MergeView is received
In-Reply-To: <9987023.1174424388661.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30066962.1188421158629.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-922?page=all ]

Brian Stansberry updated EJBTHREE-922:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handle merging of clustered SFSB state if a MergeView is received
> -----------------------------------------------------------------
>
>                 Key: EJBTHREE-922
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-922
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs. Need to work with the JBC team to design the callback and to implement a solution that will allow merging of clustered SFSB 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 lists.jboss.org  Wed Aug 29 16:59:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-78) Handling of merge
Message-ID: <23531795.1188421158842.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-78?page=all ]

Brian Stansberry updated JBCLUSTER-78:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handling of merge
> -----------------
>
>                 Key: JBCLUSTER-78
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-78
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Brian Stansberry
>             Fix For: Q3Y7
>
>
> All building blocks which involve state do *not* implement handling of merging. E.g. DRM.mergeMembers() should invoke a callback so that each subscribed listener can handle the merge.
> This needs to be done for the existing building blocks for backward compatibility, the new mechanism used is JBossCache (see link) which will handle state merging

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-78) Handling of merge
Message-ID: <29512444.1188421159027.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-78?page=all ]

Brian Stansberry updated JBCLUSTER-78:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handling of merge
> -----------------
>
>                 Key: JBCLUSTER-78
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-78
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Brian Stansberry
>             Fix For: Q3Y7
>
>
> All building blocks which involve state do *not* implement handling of merging. E.g. DRM.mergeMembers() should invoke a callback so that each subscribed listener can handle the merge.
> This needs to be done for the existing building blocks for backward compatibility, the new mechanism used is JBossCache (see link) which will handle state merging

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4223) Handle merging of
 ClusterPartition state if MergeView is received
In-Reply-To: <16889233.1174424148883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28518241.1188421159166.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4223?page=all ]

Brian Stansberry updated JBAS-4223:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handle merging of ClusterPartition state if MergeView is received
> -----------------------------------------------------------------
>
>                 Key: JBAS-4223
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4223
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4224) Handle merging of
 distributed session state if a MergeView is received
In-Reply-To: <23411494.1174424269688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12951376.1188421159311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4224?page=all ]

Brian Stansberry updated JBAS-4224:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handle merging of distributed session state if a MergeView is received
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4224
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4224
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs.  Need to work with the JBC team to design the callback and to implement a solution that will allow merging of web sessions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-922) Handle merging of
 clustered SFSB state if a MergeView is received
In-Reply-To: <9987023.1174424388661.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2761984.1188421159480.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-922?page=all ]

Brian Stansberry updated EJBTHREE-922:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handle merging of clustered SFSB state if a MergeView is received
> -----------------------------------------------------------------
>
>                 Key: EJBTHREE-922
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-922
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs. Need to work with the JBC team to design the callback and to implement a solution that will allow merging of clustered SFSB 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 lists.jboss.org  Wed Aug 29 17:01:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 17:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-8) Handling of (state)
 merging --> emission of callbacks/notifications
Message-ID: <19434115.1188421278381.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-8?page=all ]

Brian Stansberry updated JBCACHE-8:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handling of (state) merging --> emission of callbacks/notifications
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-8
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-8
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2.4SP1, 1.2.4, 1.2.4beta, 1.2.3, 1.2.2, 1.2.1, 1.2, 1.3.0.SP2, 1.3.0.SP1, 1.3.0.GA
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We need to look into handling the merge for JBossCache. Merging occurs after a network partition, or as result of 2 members starting concurrently, or as a result of a PING.timeout set too low

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 17:11:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 17:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1656) NPE when
 trying to delete
 an object in the admin portlet and cancelling the operation by pressing No
 in the confirmation dialog
In-Reply-To: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16075175.1188421878331.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1656?page=comments#action_12374480 ] 
            
Chris Laprun commented on JBPORTAL-1656:
----------------------------------------

Only happens when trying to delete a window

> NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1656
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> java.lang.NullPointerException
> 	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 17:11:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 17:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1656) NPE when
 trying to delete
 an object in the admin portlet and cancelling the operation by pressing No
 in the confirmation dialog
In-Reply-To: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24682070.1188421878461.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1656?page=comments#action_12374481 ] 
            
Chris Laprun commented on JBPORTAL-1656:
----------------------------------------

and the portlet associated with the window is not deployed...

> NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1656
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> java.lang.NullPointerException
> 	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 17:26:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 17:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16340695.1188422778278.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

Edson Tirelli closed JBRULES-1136.
----------------------------------

    Resolution: Done

Fixed.

Thanks for reporting and providing test case.

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 20:19:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 20:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1657) Improve confirm
 deletion pages
In-Reply-To: <30785252.1188411318174.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21003789.1188433158328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1657?page=all ]

Chris Laprun resolved JBPORTAL-1657.
------------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final
       Resolution: Done

> Improve confirm deletion pages
> ------------------------------
>
>                 Key: JBPORTAL-1657
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1657
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Wed Aug 29 20:21:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 20:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1656) NPE when trying
 to delete an
 object in the admin portlet and cancelling the operation by pressing No in
 the confirmation dialog
In-Reply-To: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18161147.1188433278261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1656?page=all ]

Chris Laprun resolved JBPORTAL-1656.
------------------------------------

    Resolution: Done

> NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1656
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> java.lang.NullPointerException
> 	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 20:56:24 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 20:56:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1144) Toggling
 breakpoint gives an exception
Message-ID: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>

Toggling breakpoint gives an exception
--------------------------------------

                 Key: JBRULES-1144
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1


Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 20:58:30 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 20:58:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4883883.1188435510547.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=all ]

Mark Proctor updated JBRULES-1144:
----------------------------------

    Attachment: screenshot-1.jpg

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:01:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 21:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1145) Break points do
 not work at all
Message-ID: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Break points do not work at all
-------------------------------

                 Key: JBRULES-1145
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1


Break points do not work 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 lists.jboss.org  Wed Aug 29 21:19:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 21:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1043) Make sure
 all examples work out of distro
In-Reply-To: <3531415.1186684741123.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29573193.1188436758315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1043?page=all ]

Clebert Suconic reassigned JBMESSAGING-1043:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Make sure all examples work out of distro
> -----------------------------------------
>
>                 Key: JBMESSAGING-1043
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1043
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:19:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 21:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1043) Make sure all
 examples work out of distro
In-Reply-To: <3531415.1186684741123.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28094086.1188436758522.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1043?page=all ]

Clebert Suconic closed JBMESSAGING-1043.
----------------------------------------

    Resolution: Done

> Make sure all examples work out of distro
> -----------------------------------------
>
>                 Key: JBMESSAGING-1043
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1043
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:47:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 21:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27515675.1188438438346.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=comments#action_12374513 ] 
            
Mark Proctor commented on JBRULES-1144:
---------------------------------------

Here is the stack trace:
org.drools.compiler.PackageBuilder$MissingPackageNameException: Missing package name for rule package.
at org.drools.compiler.PackageBuilder.validatePackageName(PackageBuilder.java:300)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:227)
at org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(Unknown Source)
at org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(Unknown Source)
at org.drools.eclipse.DroolsEclipsePlugin.parseResource(Unknown Source)
at org.drools.eclipse.debug.core.DroolsLineBreakpoint.setJavaBreakpointProperties(Unknown Source)
at org.drools.eclipse.debug.core.DroolsDebugTarget.breakpointAdded(Unknown Source)
at org.drools.eclipse.launching.DroolsLaunchConfigurationDelegate.launch(Unknown Source)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:639)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:565)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:754)
at org.eclipse.debug.internal.ui.DebugUIPlugin$6.run(DebugUIPlugin.java:944)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:58:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 21:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10494699.1188439098317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=all ]

Mark Proctor updated JBRULES-1144:
----------------------------------

    Attachment: screenshot-2.jpg

I did a project refresh and clean, and it looks like something deeper has gone wrong. Not a simple DRL will compile. Al with the same error.

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:16:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27128211.1188440178335.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=comments#action_12374523 ] 
            
Mark Proctor commented on JBRULES-1144:
---------------------------------------

I managed to fix this. I nucked my .metadata in eclipse and also deleted the project and re-checked it out. the errors did not re-appear. So we can probably close this off and put it down to an eclipse quirk.

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:26:38 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:26:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27140257.1188440798499.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374527 ] 
            
Mark Proctor commented on JBRULES-1145:
---------------------------------------

After nuking my .metadata it now stops at the break points, but it's still not working correctly. In the HelloWorld example in trunk, where there are two mvel rules. I put break points in both, in the first rule I can step through each line except the last. In the other rule it stops, but I can't step through at all, it just returns.

I think there is some dodgy caching going on. Initially the second rule only had two lines, so it couldn't step-over anyway, based on the bug above. I added some more lines and I still can't step-over them. I moved the location of the break point and it still stops at the old location.... very weird.

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> Break points do not work 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 lists.jboss.org  Wed Aug 29 22:28:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2459788.1188440898300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=all ]

Mark Proctor updated JBRULES-1145:
----------------------------------

    Attachment: screenshot-1.jpg

Here you can see it breaking, but there is no break point on this line.

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Wed Aug 29 22:33:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1146) No variables are
 shown for Debug points
Message-ID: <25789503.1188441198879.JavaMail.jira@cloud.prod.atl2.jboss.com>

No variables are shown for Debug points
---------------------------------------

                 Key: JBRULES-1146
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1146
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1
         Attachments: screenshot-1.jpg

No variables are showing for break points.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:33:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:33:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1146) No variables are
 shown for Debug points
In-Reply-To: <25789503.1188441198879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18935340.1188441199059.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1146?page=all ]

Mark Proctor updated JBRULES-1146:
----------------------------------

    Attachment: screenshot-1.jpg

notice in the screen shot there is no variable information

> No variables are shown for Debug points
> ---------------------------------------
>
>                 Key: JBRULES-1146
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1146
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> No variables are showing for break points.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:39:18 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Wed, 29 Aug 2007 22:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1040) add flag to
 improve
 deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
In-Reply-To: <18074307.1187995038327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33466870.1188441558553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1040?page=all ]

Andrew Rubinger reassigned EJBTHREE-1040:
-----------------------------------------

    Assignee: Andrew Rubinger  (was: William DeCoste)

> add flag to improve deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1040
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1040
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Andrew Rubinger
>            Priority: Minor
>
> Currently all jar/ejb3 files are scanned for the existence of annotated classes. This can cause slow deployment times. Create a switch with flag for only deploying jar/ejb3 files with either/or a ejb-jar.xml or jboss.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 lists.jboss.org  Thu Aug 30 02:22:18 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Thu, 30 Aug 2007 02:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1040) add flag to
 improve
 deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
In-Reply-To: <18074307.1187995038327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15943043.1188454938464.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1040?page=all ]

Andrew Rubinger updated EJBTHREE-1040:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=117427

> add flag to improve deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1040
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1040
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Andrew Rubinger
>            Priority: Minor
>
> Currently all jar/ejb3 files are scanned for the existence of annotated classes. This can cause slow deployment times. Create a switch with flag for only deploying jar/ejb3 files with either/or a ejb-jar.xml or jboss.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 lists.jboss.org  Thu Aug 30 03:39:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 03:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30979181.1188459558714.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374550 ] 
            
Dimitris Andreadis commented on JBAS-4562:
------------------------------------------

Remy, if the target for AS 5 is including JBoss Web 2.1.x, then upgrading to it as soon as possible is probably better, to reveal early on possible integration issues.

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 03:45:29 2007
From: jira-events at lists.jboss.org (Jannis Elgner (JIRA))
Date: Thu, 30 Aug 2007 03:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1604) Window state
 required but has no effect
In-Reply-To: <17779748.1184893247122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1970930.1188459929378.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1604?page=comments#action_12374551 ] 
            
Jannis Elgner commented on JBPORTAL-1604:
-----------------------------------------

You can change the windowstate with 

context.getPortalRuntimeContext().getNavigationalStateContext().setWindowState(windowA, WindowState.MINIMIZED); 

and the WindowMode with

context.getPortalRuntimeContext().getNavigationalStateContext().setMode(arg0, arg1);

instead ...

> Window state required but has no effect
> ---------------------------------------
>
>                 Key: JBPORTAL-1604
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1604
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> In 2.6 you must do this
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(org.jboss.portal.WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
> when sending an event or you get an error.  However, the window state is completely ignored (the window would not be maximized with the above).  If it is required it should have some effect -- otherwise the api should revert to before where it was not 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 lists.jboss.org  Thu Aug 30 04:55:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-196) Need an api for
 deployment/component scopes in the deployers
In-Reply-To: <28243816.1184950787176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14821462.1188464118523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-196?page=all ]

Adrian Brock updated JBMICROCONT-196:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079481#4079481

> Need an api for deployment/component scopes in the deployers
> ------------------------------------------------------------
>
>                 Key: JBMICROCONT-196
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-196
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Need to define an api for deployer scopes for jsr77
> and the metadata repository scoping.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 04:55:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-196) Need an api for
 deployment/component scopes in the deployers
In-Reply-To: <28243816.1184950787176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23993348.1188464118703.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-196?page=all ]

Adrian Brock closed JBMICROCONT-196.
------------------------------------

    Resolution: Done

This has been done, see the forum thread.

> Need an api for deployment/component scopes in the deployers
> ------------------------------------------------------------
>
>                 Key: JBMICROCONT-196
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-196
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Need to define an api for deployer scopes for jsr77
> and the metadata repository scoping.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 04:57:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-31) ClassLoading
	abstraction
Message-ID: <6322750.1188464238649.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-31?page=all ]

Adrian Brock closed JBMICROCONT-31.
-----------------------------------

    Resolution: Done

This has been done in the jboss-integration project,
see org.jboss.classloading

> ClassLoading abstraction
> ------------------------
>
>                 Key: JBMICROCONT-31
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-31
>             Project: JBoss MicroContainer
>          Issue Type: Sub-task
>          Components: General
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Need to come up with a classloading abstraction that isn't going to change in future.
> e.g. Look at jboss-aop problem with
> 3.2.x UnifiedClassLoader
> 4.0.x RepositoryClassLoader
> 5.0.x ??? (not even JMX based)
> I think the easiest way to do this to define some simple interfaces/factories
> for where this needs to be referenced 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 lists.jboss.org  Thu Aug 30 04:57:19 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:57:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-182) Integrate VFS
 ClassLoader into new deployers and jboss-head
In-Reply-To: <28277006.1183399684364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33109232.1188464239010.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-182?page=all ]

Adrian Brock closed JBMICROCONT-182.
------------------------------------

    Resolution: Done

This has been done, but the full OSGi classloading rules have not been implemented yet,
see the related task.

> Integrate VFS ClassLoader into new deployers and jboss-head
> -----------------------------------------------------------
>
>                 Key: JBMICROCONT-182
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-182
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Integrate VFSClassLoader into JBoss Head, including OSGi dependencies/versioning

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 05:11:21 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 30 Aug 2007 05:11:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <173720.1188465081983.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374558 ] 
            
Ahti Kitsik commented on JBRULES-1145:
--------------------------------------

Confirming that using drools rev14749 I get:
* Last line breakpoint is not triggered. neither for breakpoint or stepover. if the last line is commented out then even line before that is not suspended.
* no variables visible anymore

Both features worked differently/OK yesterday when mvel trunk was used.

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 05:15:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 30 Aug 2007 05:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <881445.1188465318424.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374559 ] 
            
Michael Neale commented on JBRULES-1145:
----------------------------------------

yes and there has been NO ide changes in that time either (only mvel and compiler).


> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 05:19:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 30 Aug 2007 05:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10438667.1188465558289.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374560 ] 
            
Ahti Kitsik commented on JBRULES-1145:
--------------------------------------

for me, any code after
	update ( m );
is ignored (no suspend or breakpoints).

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 06:04:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1634) Finish the
 user email
 verification after registration and when a user change his email
In-Reply-To: <21470014.1187352668490.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21649480.1188468258617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1634?page=comments#action_12374563 ] 
            
Thomas Heute commented on JBPORTAL-1634:
----------------------------------------

The missing bits are:
- When a user click on the link it should apply the new email and print a success message
- The full url must be provided to the user when clicking

> Finish the user email verification after registration and when a user change his email 
> ---------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1634
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1634
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1658) Let the identity
 UI configuration specify multiple validators on a field
Message-ID: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>

Let the identity UI configuration specify multiple validators on a field
------------------------------------------------------------------------

                 Key: JBPORTAL-1658
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Thomas Heute


In the XML configuration for identity portlets we should have:

<validators>
 <validator>...</validator>
 <validator>...</validator>
</validators>



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1658) Let the identity
 UI configuration specify multiple validators on a field
In-Reply-To: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26548358.1188468513642.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1658?page=all ]

Thomas Heute updated JBPORTAL-1658:
-----------------------------------

      Component/s: Portal Core
    Fix Version/s: 2.8 Final
         Assignee: Emanuel Muckenhuber

> Let the identity UI configuration specify multiple validators on a field
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1658
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets we should have:
> <validators>
>  <validator>...</validator>
>  <validator>...</validator>
> </validators>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10469598.1188468513807.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374564 ] 
            
Ahti Kitsik commented on JBRULES-1145:
--------------------------------------

Call to frame.getFactory().getKnownVariables() is throwing this:

java.lang.NullPointerException
	at org.mvel.integration.impl.BaseVariableResolverFactory.getKnownVariables(BaseVariableResolverFactory.java:83)
	at org.drools.base.mvel.MVELDebugHandler$MVELDebugger.onBreak(MVELDebugHandler.java:74)
	at org.mvel.debug.DebuggerContext.checkBreak(DebuggerContext.java:81)
	at org.mvel.MVELRuntime.execute(MVELRuntime.java:78)
	at org.mvel.MVEL.executeDebugger(MVEL.java:344)
	at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:39)
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550)
	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:434)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:396)
	at org.drools.examples.HelloWorldExample.main(HelloWorldExample.java:27)


> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1659) Allow for
 multiple defaut roles when a user is created
Message-ID: <31676308.1188468513944.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow for multiple defaut roles when a user is created
------------------------------------------------------

                 Key: JBPORTAL-1659
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1659
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


In the XML configuration for identity portlets, we should be able to specify multiple default 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 lists.jboss.org  Thu Aug 30 06:10:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1658) Let the identity
 UI configuration specify multiple validators on a field
In-Reply-To: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2107753.1188468618502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1658?page=all ]

Thomas Heute updated JBPORTAL-1658:
-----------------------------------

    Component/s: Portal Identity
                     (was: Portal Core)

> Let the identity UI configuration specify multiple validators on a field
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1658
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets we should have:
> <validators>
>  <validator>...</validator>
>  <validator>...</validator>
> </validators>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:14:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1660) Identity portlet
 configuration should allow to specify static and dynamic values
Message-ID: <19244245.1188468858466.JavaMail.jira@cloud.prod.atl2.jboss.com>

Identity portlet configuration should allow to specify static and dynamic values
--------------------------------------------------------------------------------

                 Key: JBPORTAL-1660
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1660
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


In the configuration file we should have something like:
<values>
    <value key="foo">Foo</value>
    <value key="bar">Bar</value>
</values>

Foo and Bar should be localized, it should check in the resource bundle for something like:
SOMEPREFIX_Foo and default to "Foo" if it doesn't exist.

For dynamic values like themes, locales and timezones we should allow the following syntax:
<values name="org.jboss.portal.THEMES"/>
<values name="org.jboss.portal.LOCALES"/>
<values name="org.jboss.portal.TIMEZONES"/>

(All the name still have to be defined, those are just 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 lists.jboss.org  Thu Aug 30 06:18:20 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:18:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1661) Remind password
 feature should be easy to turn off
Message-ID: <26688602.1188469100464.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remind password feature should be easy to turn off
--------------------------------------------------

                 Key: JBPORTAL-1661
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1661
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


Since the remind password feature requires a configured SMTP server, some users may want to disable it.

While it would work on Fedora out of the box (and probably other distro too) it could be an issue for Windows 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 lists.jboss.org  Thu Aug 30 06:20:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1662) Figure out the
 deployment issue with workflow
Message-ID: <31613999.1188469218191.JavaMail.jira@cloud.prod.atl2.jboss.com>

Figure out the deployment issue with workflow
---------------------------------------------

                 Key: JBPORTAL-1662
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1662
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Thomas Heute
             Fix For: 2.8 Final


As of now, the workflow service is started by the CMS so it would work only if the CMS service is running.

workflow.sar being deployed after portal-identity.sar (alphabetic order) we cannot easily start it in workflow.sar (i guess that it was the motivation for starting it in portal-cms.sar) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:25:18 2007
From: jira-events at lists.jboss.org (Aaman Lamba (JIRA))
Date: Thu, 30 Aug 2007 06:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18219604.1188469518749.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374566 ] 
            
Aaman Lamba commented on JBAS-4491:
-----------------------------------

Is there any update to this issue - it is pretty much a showstopper for us.The error message we receive on JBoss Startup is reproduced below, and quite similar to the original report.

===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: D:\jboss-5.0.0.Beta2

  JAVA: d:\sun\sdk\jdk\bin\java

  JAVA_OPTS:  -Dprogram.name=run.bat -server -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dsun.rmi.dgc.cl
ient.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

  CLASSPATH: d:\sun\sdk\jdk\lib\tools.jar;D:\jboss-5.0.0.Beta2\bin\run.jar

===============================================================================

14:55:46,344 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
14:55:46,376 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_
Beta2 date=200704060017)
14:55:46,376 INFO  [ServerImpl] Home Dir: D:\jboss-5.0.0.Beta2
14:55:46,376 INFO  [ServerImpl] Home URL: file:/D:/jboss-5.0.0.Beta2/
14:55:46,376 INFO  [ServerImpl] Library URL: file:/D:/jboss-5.0.0.Beta2/lib/
14:55:46,391 INFO  [ServerImpl] Patch URL: null
14:55:46,391 INFO  [ServerImpl] Server Name: default
14:55:46,391 INFO  [ServerImpl] Server Home Dir: D:\jboss-5.0.0.Beta2\server\default
14:55:46,391 INFO  [ServerImpl] Server Home URL: file:/D:/jboss-5.0.0.Beta2/server/default/
14:55:46,391 INFO  [ServerImpl] Server Data Dir: D:\jboss-5.0.0.Beta2\server\default\data
14:55:46,391 INFO  [ServerImpl] Server Temp Dir: D:\jboss-5.0.0.Beta2\server\default\tmp
14:55:46,391 INFO  [ServerImpl] Server Config URL: file:/D:/jboss-5.0.0.Beta2/server/default/conf/
14:55:46,391 INFO  [ServerImpl] Server Library URL: file:/D:/jboss-5.0.0.Beta2/server/default/lib/
14:55:46,391 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
14:55:46,422 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/D:/jboss-5.0.0.Beta2/ser
ver/default/conf/bootstrap-beans.xml
14:55:47,266 INFO  [ProfileImpl] Using profile root:D:\jboss-5.0.0.Beta2\server\default
14:55:48,860 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilte
r state=Described
java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
        at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
        at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
        at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
        at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentM
etaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
        at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(
AbstractMetaDataContext.java:280)
        at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(M
etaDataRetrievalToMetaDataBridge.java:159)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOP
ConstructorJoinpoint.java:202)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPCon
structorJoinpoint.java:172)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMe
taData(AOPConstructorJoinpoint.java:152)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJ
oinpoint.java:99)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(Kerne
lControllerContextAction.java:103)
        at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAc
tion.java:52)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelCon
trollerContextAction.java:197)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControlle
rContextAction.java:136)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerC
ontextActions.java:51)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.
java:233)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:44
5)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:5
55)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:4
89)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
        at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeplo
yer.java:302)
        at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDepl
oyer.java:272)
        at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.
java:119)
        at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:6
4)
        at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)

        at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146
)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBoots
trap.java:295)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBo
otstrap.java:222)
        at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
        at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
        at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
        at org.jboss.Main.boot(Main.java:210)
        at org.jboss.Main$1.run(Main.java:522)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
        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 org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
        ... 35 more
14:55:49,328 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
14:55:49,328 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.6.0-b105,Sun Microsystems Inc.

14:55:49,328 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
14:55:49,360 INFO  [JMXKernel] Legacy JMX core initialized
Failed to boot JBoss:
java.lang.RuntimeException: Exception during Bootstrap
        at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
        at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
        at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
        at org.jboss.Main.boot(Main.java:210)
        at org.jboss.Main$1.run(Main.java:522)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments
(SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}

VFSBootstrapScanner
 -> DeploymentFilter{Configured:**ERROR**}

VFSDeployerScanner
 -> DeploymentFilter{Configured:**ERROR**}

VFSDeploymentScanner
 -> DeploymentFilter{Configured:**ERROR**}


*** CONTEXTS IN ERROR: Name -> Error

DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;


        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileSer
viceBootstrap.java:389)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBo
otstrap.java:236)
        at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
        ... 5 more
14:57:19,568 INFO  [ServerImpl] JBoss SHUTDOWN
14:57:19,568 INFO  [ServerImpl] Undeploying all packages
Shutting down Microcontainer
14:57:19,615 INFO  [ServerImpl] Shutdown complete
Shutdown complete
Halting VM
Terminate batch job (Y/N)? y
============


> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 06:41:46 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 06:41:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4494273.1188470506360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4491?page=all ]

Adrian Brock updated JBAS-4491:
-------------------------------

    Comment: was deleted

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 06:41:46 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 06:41:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3014601.1188470506697.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4491?page=all ]

Adrian Brock updated JBAS-4491:
-------------------------------

    Comment: was deleted

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 06:50:27 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 06:50:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18964911.1188471027780.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374568 ] 
            
Adrian Brock commented on JBAS-4491:
------------------------------------

JIRA is the release notes NOT a discussion forum.
I've deleted the redundant comments.

There are perfectly good discussion forums here:
http://www.jboss.com/index.html?module=bb
if you want help.

As for this bug report.
1) It is obviously a JDK bug in Sun's 1.6, something that works in 1.5  but not 1.6 is a regression that should be
reported to the JDK provider.
2) JBoss5 doesn't even compile on JDK6 (due to changes in interfaces, e.g. the jdbc interfaces) 
and certainly hasn't been tested on it either

It is planned to make JBoss5 work with JDK6 including regular regression testing.

This bug report will almost certainly be closed as "Won't Fix" once we know for certain that this is JDK bug
in early releases of Sun's 1.6 JDK.

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 07:09:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 07:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1626) FIrst access to
 a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14921485.1188472158342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=all ]

Thomas Heute updated JBPORTAL-1626:
-----------------------------------

    Priority: Critical  (was: Major)

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 07:11:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 07:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24578480.1188472278366.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12374569 ] 
            
Thomas Heute commented on JBPORTAL-1626:
----------------------------------------

It's actually breaking with JBoss AS 4.2.1.GA (works fine with 4.0.5)

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 07:38:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 07:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19048467.1188473898474.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4563?page=comments#action_12374570 ] 
            
Dimitris Andreadis commented on JBAS-4563:
------------------------------------------

We need to hurry up with the hibernate upgrades.

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 07:40:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 07:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.2
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33350245.1188474018228.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374571 ] 
            
Dimitris Andreadis commented on JBAS-4564:
------------------------------------------

Same here, we have limited time to perform library updates and solve any integration issues that may come up.

> Hibernate EntityManager 3.3.2
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 08:01:20 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 30 Aug 2007 08:01:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1658) Let the
 identity UI configuration specify multiple validators on a field
In-Reply-To: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14697399.1188475280457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1658?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1658.
-------------------------------------------

    Resolution: Done

example usage: validatorId="metadata.email.validators[0]" or validatorId="metadataservice.email.validator" to get the first validator of the list

> Let the identity UI configuration specify multiple validators on a field
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1658
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets we should have:
> <validators>
>  <validator>...</validator>
>  <validator>...</validator>
> </validators>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 08:16:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Aug 2007 08:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-585) FD_SOCK: make
 fetching of cache asynchronous
Message-ID: <29535831.1188476178345.JavaMail.jira@cloud.prod.atl2.jboss.com>

FD_SOCK: make fetching of cache asynchronous
--------------------------------------------

                 Key: JGRP-585
                 URL: http://jira.jboss.com/jira/browse/JGRP-585
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


FD_SOCK fetches the cache *synchronously* on down(VIEW_CHANGE). This blocks until the cache has been received, blocking down() and therefore other down calls. This could for example block a JOIN_RSP to a new joiner, causing the JOIN_REQ to fail.
[Vladimir]
Trying to dig into the trenches in order to understand why exactly is ConcurrentStartupTest failing if we switch up and down view sending in GMS#installView! I noticed that FD_SOCK in down for VIEW_CHANGE event does a very unusual thing: synchronous mcast invocation and it does it repeatedly until succeeds in getting cache contents or timeouts. But it does not look like it is 100% necessary to do this? Can't we abstract getting cache contents into a task that is run on a timer until we get a result? So we effectively we make getting cache contents asynchronous that does not potentially block view installation for quite a while because as it is now - this is what is happening.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 08:30:18 2007
From: jira-events at lists.jboss.org (Matthias Raab (JIRA))
Date: Thu, 30 Aug 2007 08:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-96) SUN JDK 1.5 on client
 side and IBM JDK 1.5 on server side doesn't work together
Message-ID: <2193288.1188477018845.JavaMail.jira@cloud.prod.atl2.jboss.com>

SUN JDK 1.5 on client side and IBM JDK 1.5 on server side doesn't work together
-------------------------------------------------------------------------------

                 Key: JBSER-96
                 URL: http://jira.jboss.com/jira/browse/JBSER-96
             Project: JBoss Serialization
          Issue Type: Bug
    Affects Versions: 1.0.3 GA
         Environment: 1. Client: Windows, SUN JDK 1.5.0_12, JBoss Client
2. Server: AS/400 with i5, IBM JKD 1.5 (J9), JBoss Server
            Reporter: Matthias Raab
         Assigned To: Clebert Suconic
            Priority: Critical


Failure during serialization on client side: "Current classpath has lesser fields on java.math.BigDecimal than its original version"
Stacktrace
java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at de.carus.cjfc.tfc.dto.TMDTOExchange.readExternal(TMDTOExchange.java:3092)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78)
	at org.jboss.invocation.http.interfaces.Util.invoke(Util.java:169)
	at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:103)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
	at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
	at $Proxy5.read(Unknown Source)
	at de.carus.cjfc.tfc.bu.ejb.TMUseCaseMgrEJBClient.read(TMUseCaseMgrEJBClient.java:246)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.executeSearch(TMUseCaseMgr.java:1702)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.search(TMUseCaseMgr.java:1686)
	at de.carus.cjfc.tfc.bu.model.TMModelContext.search(TMModelContext.java:212)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:427)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:400)
	at de.alea.amc.core.bu.usecase.center.UCCompanySelector.find(UCCompanySelector.java:177)
	at de.alea.amc.core.bu.model.user.MAMCUser.getAllowedSystemClients(MAMCUser.java:529)
	at de.alea.amc.core.pr.swt.user.LoginDialog.okPressed(LoginDialog.java:207)
	at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:464)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:616)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
	at org.eclipse.jface.window.Window.open(Window.java:796)
	at de.alea.amc.core.pr.swt.user.LoginAction.run(LoginAction.java:30)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.runStartActions(AmcRunnable.java:133)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.run(AmcRunnable.java:52)
	at de.alea.amc.pr.swt.rcpframe.AMCSafeRunnableRunner.run(AMCSafeRunnableRunner.java:48)
	at de.alea.amc.pr.AmcRunnable.run(AmcRunnable.java:165)
	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.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAppContainer.java:533)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:155)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 63 more
Caused by: java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 67 more
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 81 more
Caused by: java.io.IOException: Current classpath has lesser fields on java.math.BigDecimal than its original version
	at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 85 more
java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at de.carus.cjfc.tfc.dto.TMDTOExchange.readExternal(TMDTOExchange.java:3092)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78)
	at org.jboss.invocation.http.interfaces.Util.invoke(Util.java:169)
	at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:103)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
	at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
	at $Proxy5.read(Unknown Source)
	at de.carus.cjfc.tfc.bu.ejb.TMUseCaseMgrEJBClient.read(TMUseCaseMgrEJBClient.java:246)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.executeSearch(TMUseCaseMgr.java:1702)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.search(TMUseCaseMgr.java:1686)
	at de.carus.cjfc.tfc.bu.model.TMModelContext.search(TMModelContext.java:212)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:427)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:400)
	at de.alea.amc.core.bu.usecase.center.UCCompanySelector.find(UCCompanySelector.java:177)
	at de.alea.amc.core.bu.model.user.MAMCUser.getAllowedSystemClients(MAMCUser.java:529)
	at de.alea.amc.core.pr.swt.user.LoginDialog.okPressed(LoginDialog.java:207)
	at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:464)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:616)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
	at org.eclipse.jface.window.Window.open(Window.java:796)
	at de.alea.amc.core.pr.swt.user.LoginAction.run(LoginAction.java:30)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.runStartActions(AmcRunnable.java:133)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.run(AmcRunnable.java:52)
	at de.alea.amc.pr.swt.rcpframe.AMCSafeRunnableRunner.run(AMCSafeRunnableRunner.java:48)
	at de.alea.amc.pr.AmcRunnable.run(AmcRunnable.java:165)
	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.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAppContainer.java:533)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:155)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 63 more
Caused by: java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 67 more
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 81 more
Caused by: java.io.IOException: Current classpath has lesser fields on java.math.BigDecimal than its original version
	at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 85 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 lists.jboss.org  Thu Aug 30 08:38:18 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 30 Aug 2007 08:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
In-Reply-To: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2375390.1188477498396.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4643?page=comments#action_12374586 ] 
            
Alexey Loubyansky commented on JBAS-4643:
-----------------------------------------

For the org.jboss.test.xml.DDValidatorUnitTestCase there is still one test failing because the XML is referencing http://www.jboss.org/j2ee/schema/jboss_5_0.xsd which does not exist. The file is
trunk\testsuite\output\resources\naming\jar\META-INF\jboss.xml

> Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
> -----------------------------------------------------------
>
>                 Key: JBAS-4643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
> junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)
>  9.162 
> testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
> junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)
>  2.797 
> testJBossCmpJdbc Success  0.994 
> testWebXml Success  1.930 
> testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
> junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)
>  0.455 
> testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
> junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)
>  0.635 
> testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
> junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)
>  0.825 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 09:15:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 09:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-763) Release 2.2.1.GA
In-Reply-To: <16838776.1183317717648.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22538350.1188479729128.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-763?page=comments#action_12374595 ] 
            
Dimitris Andreadis commented on JBREM-763:
------------------------------------------

I suppose this can be closed?

> Release 2.2.1.GA
> ----------------
>
>                 Key: JBREM-763
>                 URL: http://jira.jboss.com/jira/browse/JBREM-763
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.GA
>
>
> This release contains bug fixes for JBREM-747, JBREM-748, JBREM-751, and JBREM-761.  It is intended for inclusion with community JBossAS 4.2.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 lists.jboss.org  Thu Aug 30 09:29:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 09:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1147) Release 4.0.1
	version
Message-ID: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release 4.0.1 version
---------------------

                 Key: JBRULES-1147
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Fernando Meyer
             Fix For: 4.0.1


Release 4.0.1 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 lists.jboss.org  Thu Aug 30 09:55:18 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 30 Aug 2007 09:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
In-Reply-To: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30097897.1188482118265.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4643?page=comments#action_12374607 ] 
            
Alexey Loubyansky commented on JBAS-4643:
-----------------------------------------

The SingletonSchemaBindingResolverUnitTestCase was missing an XSD. It's fixed now.

> Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
> -----------------------------------------------------------
>
>                 Key: JBAS-4643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
> junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)
>  9.162 
> testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
> junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)
>  2.797 
> testJBossCmpJdbc Success  0.994 
> testWebXml Success  1.930 
> testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
> junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)
>  0.455 
> testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
> junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)
>  0.635 
> testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
> junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)
>  0.825 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 10:09:18 2007
From: jira-events at lists.jboss.org (eymeric vieuille (JIRA))
Date: Thu, 30 Aug 2007 10:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
Message-ID: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>

Out of memory exception asserting more than 100 facts
-----------------------------------------------------

                 Key: JBRULES-1148
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions:  4.0.0.GA
         Environment: JDK 1.5; OS = Windows 2000 pro.

For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
            Reporter: eymeric vieuille
         Assigned To: Mark Proctor
             Fix For:  4.0.0.GA
         Attachments: Out_Of_Memory_Test.zip

I got a java.lang.OutOfMemoryException when I assert more than 100 objects.

I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)

You can see there logs obtained launching the sample project main class :

Launching RULES ENGINE
100 Facts
Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 10:09:18 2007
From: jira-events at lists.jboss.org (eymeric vieuille (JIRA))
Date: Thu, 30 Aug 2007 10:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
In-Reply-To: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18310066.1188482958821.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1148?page=all ]

eymeric vieuille updated JBRULES-1148:
--------------------------------------

    Attachment: Out_Of_Memory_Test.zip

Sample project.

> Out of memory exception asserting more than 100 facts
> -----------------------------------------------------
>
>                 Key: JBRULES-1148
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: JDK 1.5; OS = Windows 2000 pro.
> For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
>            Reporter: eymeric vieuille
>         Assigned To: Mark Proctor
>             Fix For:  4.0.0.GA
>
>         Attachments: Out_Of_Memory_Test.zip
>
>
> I got a java.lang.OutOfMemoryException when I assert more than 100 objects.
> I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)
> You can see there logs obtained launching the sample project main class :
> Launching RULES ENGINE
> 100 Facts
> Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
> Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 10:17:25 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 30 Aug 2007 10:17:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1147) Release 4.0.1
	version
In-Reply-To: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26023052.1188483445535.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1147?page=comments#action_12374615 ] 
            
Fernando Meyer commented on JBRULES-1147:
-----------------------------------------

created tag https://svn.labs.jboss.com/labs/jbossrules/tags/4.0.1.14754GA 

> Release 4.0.1 version
> ---------------------
>
>                 Key: JBRULES-1147
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Release 4.0.1 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 lists.jboss.org  Thu Aug 30 10:19:19 2007
From: jira-events at lists.jboss.org (Work Related (JIRA))
Date: Thu, 30 Aug 2007 10:19:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1663) can images be
	used in tabs
Message-ID: <20788483.1188483559584.JavaMail.jira@cloud.prod.atl2.jboss.com>

can images be used in tabs
--------------------------

                 Key: JBPORTAL-1663
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1663
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final
            Reporter: Work Related
            Priority: Optional


can anyone please tell me if we can use images as tabs in jboss portal 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 lists.jboss.org  Thu Aug 30 10:22:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 10:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1663) can images be
	used in tabs
In-Reply-To: <20788483.1188483559584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2577759.1188483769399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1663?page=all ]

Thomas Heute resolved JBPORTAL-1663.
------------------------------------

    Resolution: Rejected

For questions please use the forum, Jira is used to report confirmed bugs

> can images be used in tabs
> --------------------------
>
>                 Key: JBPORTAL-1663
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1663
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>            Reporter: Work Related
>            Priority: Optional
>
> can anyone please tell me if we can use images as tabs in jboss portal 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 lists.jboss.org  Thu Aug 30 10:29:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 10:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-412) Look into source
 level dependencies with maven
Message-ID: <27076786.1188484158359.JavaMail.jira@cloud.prod.atl2.jboss.com>

Look into source level dependencies with maven
----------------------------------------------

                 Key: JBBUILD-412
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-412
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - Maint 2007


Steve brought up the issue of not being able to use intermodule dependencies without installing the modules.  In other words, you should be able to make a fix in one module, and then be able to use the fix in another module without installing the first module.
Also, you should be able to run a mvn compile of a multi-module project with inter-module deps with an empty 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 lists.jboss.org  Thu Aug 30 10:31:18 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Thu, 30 Aug 2007 10:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15511388.1188484278348.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374619 ] 
            
Remy Maucherat commented on JBAS-4562:
--------------------------------------

Right, even if some functionality is only API complete at the moment (the Comet IO fonctionality updates), the core functionality is ok, so I can update the AS 5 branch to it sooner rather than later (before the end of the week would be ok ?).

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 10:38:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 10:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21984324.1188484698353.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374620 ] 
            
Dimitris Andreadis commented on JBAS-4562:
------------------------------------------

That's fine.

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 11:04:19 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Aug 2007 11:04:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25393062.1188486259887.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]

Bela Ban updated JGRP-507:
--------------------------

    Fix Version/s: 2.6

Will look at it in the 2.6 release time frame 9although it won't probably get fixed in 2.6 as 2.6 doesn't seem to have this problem).

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1, 2.3, 2.4.1 SP2, 2.4.1 SP1, 2.4.1, 2.4, 2.2.9 SP4, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.2.7 SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Thu Aug 30 11:11:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 30 Aug 2007 11:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11559250.1188486678301.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-507?page=comments#action_12374627 ] 
            
Galder Zamarreno commented on JGRP-507:
---------------------------------------

Bela, it was fixed in 2.4.1.SP3. I just posted the link to the case that raised 
this a few months ago.

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1, 2.3, 2.4.1 SP2, 2.4.1 SP1, 2.4.1, 2.4, 2.2.9 SP4, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.2.7 SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Thu Aug 30 11:40:54 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 11:40:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
In-Reply-To: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18794185.1188488454529.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1148?page=all ]

Edson Tirelli reassigned JBRULES-1148:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Out of memory exception asserting more than 100 facts
> -----------------------------------------------------
>
>                 Key: JBRULES-1148
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: JDK 1.5; OS = Windows 2000 pro.
> For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
>            Reporter: eymeric vieuille
>         Assigned To: Edson Tirelli
>             Fix For:  4.0.0.GA
>
>         Attachments: Out_Of_Memory_Test.zip
>
>
> I got a java.lang.OutOfMemoryException when I assert more than 100 objects.
> I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)
> You can see there logs obtained launching the sample project main class :
> Launching RULES ENGINE
> 100 Facts
> Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
> Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 11:42:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 11:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
In-Reply-To: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9311341.1188488538418.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1148?page=all ]

Edson Tirelli updated JBRULES-1148:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was:  4.0.0.GA)

> Out of memory exception asserting more than 100 facts
> -----------------------------------------------------
>
>                 Key: JBRULES-1148
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: JDK 1.5; OS = Windows 2000 pro.
> For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
>            Reporter: eymeric vieuille
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.2
>
>         Attachments: Out_Of_Memory_Test.zip
>
>
> I got a java.lang.OutOfMemoryException when I assert more than 100 objects.
> I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)
> You can see there logs obtained launching the sample project main class :
> Launching RULES ENGINE
> 100 Facts
> Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
> Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 11:57:18 2007
From: jira-events at lists.jboss.org (Greg Zoller (JIRA))
Date: Thu, 30 Aug 2007 11:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2948109.1188489438717.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374628 ] 
            
Greg Zoller commented on JBAS-4491:
-----------------------------------

Adrian,

Actually I found some more info on this "bug".  It appears to be a bug in the JDK but it is not.  Sun says that there was some ambiguity/misinterpretation of certain functionality of class loading that permitted developers to get away with some common things that strictly speaking were not part of the Java spec.  Java 6 simply closed the loophole. 

So while the behavior is not really a "bug" per se the change certainly does impact a lot of software out there and unfortunately the onus is on software providers like JBoss, not Sun, to rectify the problems this causes.  Sun is not and will not likely be open to treat this as a regression issue since in their minds the "feature" in question probably never should have worked in the first place.  Providers that don't rework the affected bits of their code may find themselves effectively stuck on JDK5.

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 12:11:19 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-32)
 org.jboss.util.propertyeditor.PropertiesEditor should preserve the string
 text
Message-ID: <11342281.1188490279179.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.util.propertyeditor.PropertiesEditor should preserve the string text
------------------------------------------------------------------------------

                 Key: JBCOMMON-32
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-32
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: common-core
    Affects Versions: 2.0.0.GA
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: 2.2.1.GA


Many of our property editors extend org.jboss.util.propertyeditor.TextPropertyEditorSupport and operate in a reverse mode, i.e they store the string form of a property and convert to object whenever getValue() is called (rather than storing a converted object). 

In this way the string form remains intact, so there is no property replacement if you ask back the string with getAsText(). 

org.jboss.util.propertyeditor.PropertiesEditor in JBoss Common 1.x operates like this, but it was changed some time ago in jboss head (now jboss commons 2.x.)

This causes a test failure in the AS testsuite since getAsText() 
- doesn't preserve the property item order 
- resolves ${whatever} 
- includes the leading #timestamp 

I'll revert that change and essentially synch org.jboss.util.propertyeditor.PropertiesEditor  with jboss common 1.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 lists.jboss.org  Thu Aug 30 12:13:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-32)
 org.jboss.util.propertyeditor.PropertiesEditor should preserve the string
 text
In-Reply-To: <11342281.1188490279179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13666335.1188490409918.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-32?page=all ]

Dimitris Andreadis closed JBCOMMON-32.
--------------------------------------

    Resolution: Done

Done.

> org.jboss.util.propertyeditor.PropertiesEditor should preserve the string text
> ------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-32
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-32
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common-core
>    Affects Versions: 2.0.0.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: 2.2.1.GA
>
>
> Many of our property editors extend org.jboss.util.propertyeditor.TextPropertyEditorSupport and operate in a reverse mode, i.e they store the string form of a property and convert to object whenever getValue() is called (rather than storing a converted object). 
> In this way the string form remains intact, so there is no property replacement if you ask back the string with getAsText(). 
> org.jboss.util.propertyeditor.PropertiesEditor in JBoss Common 1.x operates like this, but it was changed some time ago in jboss head (now jboss commons 2.x.)
> This causes a test failure in the AS testsuite since getAsText() 
> - doesn't preserve the property item order 
> - resolves ${whatever} 
> - includes the leading #timestamp 
> I'll revert that change and essentially synch org.jboss.util.propertyeditor.PropertiesEditor  with jboss common 1.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 lists.jboss.org  Thu Aug 30 12:22:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 12:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
Message-ID: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>

Parser is only saving last CE for prefixed AND/OR 
--------------------------------------------------

                 Key: JBRULES-1149
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli


Reported by user:

Hi,

I have a problem with this execution :

rule "Your First Rule"

when
 (or
 not Venue()
 (and v:Venue()
       l:ListeSousVenue()
       p:Param()))
then
 System.out.println("OK - 1");
end

rule "Your Second Rule"

when
 (or
 not Venue()
 (and p:Param()
       l:ListeSousVenue()
       v:Venue()))
then
   System.out.println("OK - 2");
end

In my WM, I have a Param and a ListeSousVenue but no Venue
But after execution, I have just this result :
"OK - 1"

Why the second rule doesn't execute ?

Thanks,

Vdelbart


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:33:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Thu, 30 Aug 2007 12:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31702140.1188491598257.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4563?page=comments#action_12374631 ] 
            
Emmanuel Bernard commented on JBAS-4563:
----------------------------------------

This does not come up at the best time for me.
If you want to start integration tests, I suggest moving to 3.3.0
3.3.1 is about bugfixing, we can move it to the next AS release (CR?)

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:33:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Thu, 30 Aug 2007 12:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.2
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27400812.1188491598382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374632 ] 
            
Emmanuel Bernard commented on JBAS-4564:
----------------------------------------

This does not come up at the best time for me.
If you want to start integration tests, I suggest moving to 3.3.1
3.3.2 is about bugfixing and removing the evil archive browser dependency, we can move it to the next AS release (CR?)

> Hibernate EntityManager 3.3.2
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:37:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 12:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
In-Reply-To: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30487949.1188491838429.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1149?page=all ]

Edson Tirelli closed JBRULES-1149.
----------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

Fixed

> Parser is only saving last CE for prefixed AND/OR 
> --------------------------------------------------
>
>                 Key: JBRULES-1149
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Reported by user:
> Hi,
> I have a problem with this execution :
> rule "Your First Rule"
> when
>  (or
>  not Venue()
>  (and v:Venue()
>        l:ListeSousVenue()
>        p:Param()))
> then
>  System.out.println("OK - 1");
> end
> rule "Your Second Rule"
> when
>  (or
>  not Venue()
>  (and p:Param()
>        l:ListeSousVenue()
>        v:Venue()))
> then
>    System.out.println("OK - 2");
> end
> In my WM, I have a Param and a ListeSousVenue but no Venue
> But after execution, I have just this result :
> "OK - 1"
> Why the second rule doesn't execute ?
> Thanks,
> Vdelbart

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:48:18 2007
From: jira-events at lists.jboss.org (Jay Howell (JIRA))
Date: Thu, 30 Aug 2007 12:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1062) Receiving
 constraint violation when messages are persisted
Message-ID: <8759234.1188492498449.JavaMail.jira@cloud.prod.atl2.jboss.com>

Receiving constraint violation when messages are persisted
----------------------------------------------------------

                 Key: JBMESSAGING-1062
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1062
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
            Reporter: Jay Howell
         Assigned To: Tim Fox


When a message is persisted, the db throws a constraint violation.   JBM detects it as a deadlock and tries it again.  It works the second time.  This seems to be a race condition between the entries put in the JBM_MSG_REF and the JBM_MSG tables.  The entry must be fully in the JBM_MSG before the entry can be put in the JBM_MSG_REF table due to the FK constraint on MESSAGE_ID.  I also saw another customer with the same problem just after the 1.4.0 CR1 release post the same in the forums...

Here's the Log snippet...

2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
java.sql.BatchUpdateException: com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the FOREIGN KEY constraint "FK__JBM_MSG_R__MESSA__575DE8F7". The conflict occurred in database "crs5_jms_deep", table "dbo.JBM_MSG", column 'MESSAGE_ID'.
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(Unknown Source)
at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:478)
at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:519)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2911)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetryBatch(JDBCPersistenceManager.java:2791)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1675)
at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:3149)
at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:451)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1550)
at org.jboss.remoting.Client.invoke(Client.java:530)
at org.jboss.remoting.Client.invoke(Client.java:518)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:226)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:107)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
at org.jboss.jms.tx.ResourceManager.commitLocal(ResourceManager.java:208)
at org.jboss.jms.client.container.SessionAspect.handleCommit(SessionAspect.java:556)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect26.invoke(SessionAspect26.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossSession.commit(JBossSession.java:164)
at org.springframework.jms.connection.JmsResourceHolder.commitAll(JmsResourceHolder.java:173)
at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.afterCommit(ConnectionFactoryUtils.java:380)
at org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:90)
at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:76)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:861)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:704)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:126)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy146.commit(Unknown Source)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at com.crsoftwareinc.crs.core.domain.aop.advice.UpsertComponentIdMethodInterceptor.invoke(UpsertComponentIdMethodInterceptor.java:201)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy440.generateReportBySystemCriteria(Unknown Source)
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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy440.generateReportBySystemCriteria(Unknown Source)
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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:70)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy439.generateReportBySystemCriteria(Unknown Source)
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.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)
at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:475)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:440)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:193)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Trying again after a pause
2007-08-29 08:47:04,421 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Update worked after retry
2007-08-29 08:47:04,421 DEBUG [org.jboss.remoting.ServerInvoker] Thread pool class supplied is not an object 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 lists.jboss.org  Thu Aug 30 12:50:18 2007
From: jira-events at lists.jboss.org (Jay Howell (JIRA))
Date: Thu, 30 Aug 2007 12:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1062) Receiving
 constraint violation when messages are persisted
In-Reply-To: <8759234.1188492498449.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32641104.1188492618442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1062?page=all ]

Jay Howell updated JBMESSAGING-1062:
------------------------------------

    Workaround Description: 
open your mssql-persistence-service
change the line from
CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (CHANNEL_ID BIGINT, MESSAGE_ID BIGINT REFERENCES JBM_MSG(MESSAGE_ID), TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INT, SCHED_DELIVERY BIGINT, PRIMARY KEY(CHANNEL_ID, MESSAGE_ID))

to

CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (CHANNEL_ID BIGINT, MESSAGE_ID BIGINT, TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INT, SCHED_DELIVERY BIGINT, PRIMARY KEY(CHANNEL_ID, MESSAGE_ID))


> Receiving constraint violation when messages are persisted
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1062
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1062
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>            Reporter: Jay Howell
>         Assigned To: Tim Fox
>
> When a message is persisted, the db throws a constraint violation.   JBM detects it as a deadlock and tries it again.  It works the second time.  This seems to be a race condition between the entries put in the JBM_MSG_REF and the JBM_MSG tables.  The entry must be fully in the JBM_MSG before the entry can be put in the JBM_MSG_REF table due to the FK constraint on MESSAGE_ID.  I also saw another customer with the same problem just after the 1.4.0 CR1 release post the same in the forums...
> Here's the Log snippet...
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
> java.sql.BatchUpdateException: com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the FOREIGN KEY constraint "FK__JBM_MSG_R__MESSA__575DE8F7". The conflict occurred in database "crs5_jms_deep", table "dbo.JBM_MSG", column 'MESSAGE_ID'.
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(Unknown Source)
> at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:478)
> at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:519)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2911)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetryBatch(JDBCPersistenceManager.java:2791)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1675)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:3149)
> at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:451)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
> at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
> at org.jboss.remoting.Client.invoke(Client.java:1550)
> at org.jboss.remoting.Client.invoke(Client.java:530)
> at org.jboss.remoting.Client.invoke(Client.java:518)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:226)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:107)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
> at org.jboss.jms.tx.ResourceManager.commitLocal(ResourceManager.java:208)
> at org.jboss.jms.client.container.SessionAspect.handleCommit(SessionAspect.java:556)
> at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect26.invoke(SessionAspect26.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
> at org.jboss.jms.client.JBossSession.commit(JBossSession.java:164)
> at org.springframework.jms.connection.JmsResourceHolder.commitAll(JmsResourceHolder.java:173)
> at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.afterCommit(ConnectionFactoryUtils.java:380)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:90)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:76)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:861)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:704)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
> at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:126)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy146.commit(Unknown Source)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at com.crsoftwareinc.crs.core.domain.aop.advice.UpsertComponentIdMethodInterceptor.invoke(UpsertComponentIdMethodInterceptor.java:201)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:70)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy439.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)
> at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
> at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
> at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
> at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
> at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)
> at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:475)
> at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:440)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:193)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Trying again after a pause
> 2007-08-29 08:47:04,421 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Update worked after retry
> 2007-08-29 08:47:04,421 DEBUG [org.jboss.remoting.ServerInvoker] Thread pool class supplied is not an object 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 lists.jboss.org  Thu Aug 30 12:52:18 2007
From: jira-events at lists.jboss.org (Jay Howell (JIRA))
Date: Thu, 30 Aug 2007 12:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1062) Receiving
 constraint violation when messages are persisted
In-Reply-To: <8759234.1188492498449.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2409366.1188492738486.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1062?page=all ]

Jay Howell resolved JBMESSAGING-1062.
-------------------------------------

    Fix Version/s: 1.4.0.CR2
       Resolution: Done

This is fixed in CR2, the sql no longer has the constraint defined.

> Receiving constraint violation when messages are persisted
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1062
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1062
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>            Reporter: Jay Howell
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> When a message is persisted, the db throws a constraint violation.   JBM detects it as a deadlock and tries it again.  It works the second time.  This seems to be a race condition between the entries put in the JBM_MSG_REF and the JBM_MSG tables.  The entry must be fully in the JBM_MSG before the entry can be put in the JBM_MSG_REF table due to the FK constraint on MESSAGE_ID.  I also saw another customer with the same problem just after the 1.4.0 CR1 release post the same in the forums...
> Here's the Log snippet...
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
> java.sql.BatchUpdateException: com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the FOREIGN KEY constraint "FK__JBM_MSG_R__MESSA__575DE8F7". The conflict occurred in database "crs5_jms_deep", table "dbo.JBM_MSG", column 'MESSAGE_ID'.
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(Unknown Source)
> at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:478)
> at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:519)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2911)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetryBatch(JDBCPersistenceManager.java:2791)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1675)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:3149)
> at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:451)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
> at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
> at org.jboss.remoting.Client.invoke(Client.java:1550)
> at org.jboss.remoting.Client.invoke(Client.java:530)
> at org.jboss.remoting.Client.invoke(Client.java:518)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:226)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:107)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
> at org.jboss.jms.tx.ResourceManager.commitLocal(ResourceManager.java:208)
> at org.jboss.jms.client.container.SessionAspect.handleCommit(SessionAspect.java:556)
> at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect26.invoke(SessionAspect26.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
> at org.jboss.jms.client.JBossSession.commit(JBossSession.java:164)
> at org.springframework.jms.connection.JmsResourceHolder.commitAll(JmsResourceHolder.java:173)
> at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.afterCommit(ConnectionFactoryUtils.java:380)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:90)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:76)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:861)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:704)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
> at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:126)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy146.commit(Unknown Source)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at com.crsoftwareinc.crs.core.domain.aop.advice.UpsertComponentIdMethodInterceptor.invoke(UpsertComponentIdMethodInterceptor.java:201)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:70)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy439.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)
> at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
> at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
> at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
> at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
> at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)
> at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:475)
> at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:440)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:193)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Trying again after a pause
> 2007-08-29 08:47:04,421 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Update worked after retry
> 2007-08-29 08:47:04,421 DEBUG [org.jboss.remoting.ServerInvoker] Thread pool class supplied is not an object 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 lists.jboss.org  Thu Aug 30 12:57:35 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4652) Upgrade Hibernate
 Annotations to 3.3.1 (from 3.3.0)
Message-ID: <18571647.1188493055253.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade Hibernate Annotations to 3.3.1 (from 3.3.0)
---------------------------------------------------

                 Key: JBAS-4652
                 URL: http://jira.jboss.com/jira/browse/JBAS-4652
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Hibernate service
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-5.0.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 lists.jboss.org  Thu Aug 30 12:57:35 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 30 Aug 2007 12:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1659) Allow for
 multiple defaut roles when a user is created
In-Reply-To: <31676308.1188468513944.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24670667.1188493055832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1659?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1659.
-------------------------------------------

    Resolution: Done

done

> Allow for multiple defaut roles when a user is created
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1659
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1659
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets, we should be able to specify multiple default 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 lists.jboss.org  Thu Aug 30 12:57:35 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.0
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14403372.1188493055963.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4563?page=all ]

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Summary: Hibernate Annotations 3.3.0  (was: Hibernate Annotations 3.3.1)

Change version in the title.

> Hibernate Annotations 3.3.0
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:59:18 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 30 Aug 2007 12:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1661) Remind password
 feature should be easy to turn off
In-Reply-To: <26688602.1188469100464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17017386.1188493158556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1661?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1661.
-------------------------------------------

    Resolution: Done

atm you can turn it of by setting the portlet-preference-value 'lostPassword' to false

> Remind password feature should be easy to turn off
> --------------------------------------------------
>
>                 Key: JBPORTAL-1661
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1661
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> Since the remind password feature requires a configured SMTP server, some users may want to disable it.
> While it would work on Fedora out of the box (and probably other distro too) it could be an issue for Windows 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 lists.jboss.org  Thu Aug 30 13:01:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 13:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3116785.1188493278248.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4564?page=all ]

Dimitris Andreadis updated JBAS-4564:
-------------------------------------

    Summary: Hibernate EntityManager 3.3.1  (was: Hibernate EntityManager 3.3.2)

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 13:01:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 13:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4653) Upgrade Hibernate
 Entity Manager to 3.3.2 (from 3.3.1)
Message-ID: <24362884.1188493278361.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade Hibernate Entity Manager to 3.3.2 (from 3.3.1)
------------------------------------------------------

                 Key: JBAS-4653
                 URL: http://jira.jboss.com/jira/browse/JBAS-4653
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Hibernate service
    Affects Versions:  JBossAS-5.0.0.Beta3
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-5.0.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 lists.jboss.org  Thu Aug 30 13:03:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 13:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4652) Upgrade Hibernate
 Annotations to 3.3.1 (from 3.3.0)
In-Reply-To: <18571647.1188493055253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18958515.1188493398299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4652?page=all ]

Dimitris Andreadis updated JBAS-4652:
-------------------------------------

    Affects Version/s:  JBossAS-5.0.0.Beta3
                           (was: JBossAS-5.0.0.Beta2)

> Upgrade Hibernate Annotations to 3.3.1 (from 3.3.0)
> ---------------------------------------------------
>
>                 Key: JBAS-4652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4652
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>    Affects Versions:  JBossAS-5.0.0.Beta3
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Thu Aug 30 13:10:18 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 30 Aug 2007 13:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-204) Problem
 determing getter for java.lang.Boolean property
Message-ID: <18770961.1188493818213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem determing getter for java.lang.Boolean property
-------------------------------------------------------

                 Key: JBMICROCONT-204
                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-204
             Project: JBoss MicroContainer
          Issue Type: Bug
          Components: BeanInfo
    Affects Versions:  JBossMC_2_0_0 Beta3
         Environment: org.jboss.test.deployers.managed.test.DeployerManagedDeploymentUnitTestCase.testManagedDeployment
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossMC-2.0.0.Beta4


Trying to create a ManagedProperty for a boolean like:

   @ManagementProperty(name="local-transaction")
   public Boolean isLocalTransactions()
   {
      return localTransactions;
   }

   public void setLocalTransactions(Boolean localTransactions)
   {
      this.localTransactions = localTransactions;
   }

is failing in the AbstractPropertyInfo accessor because there is no getter:

Caused by: java.lang.IllegalArgumentException: Property is not readable: localTransactions for org.jboss.test.deployers.deployer.support.LocalDataSourceMetaData
	at org.jboss.beans.info.plugins.AbstractPropertyInfo.get(AbstractPropertyInfo.java:170)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.getValue(AbstractManagedObjectFactory.java:581)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.java:534)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFactory.java:485)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:166)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.getValue(AbstractManagedObjectFactory.java:622)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.java:534)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFactory.java:485)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:166)
	at org.jboss.test.deployers.deployer.support.MCFDeployer.build(MCFDeployer.java:40)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.build(DeployerWrapper.java:202)
	... 21 more

This works fine if the setter/getter use the primitive boolean type rather than java.lang.Boolean.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 14:33:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 14:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1655) Improve
	"rename" forms
In-Reply-To: <2649337.1188411092173.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29815077.1188498798354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1655?page=all ]

Chris Laprun resolved JBPORTAL-1655.
------------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final
       Resolution: Done

> Improve "rename" forms
> ----------------------
>
>                 Key: JBPORTAL-1655
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1655
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 14:33:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 14:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1655) Improve "rename"
	forms
In-Reply-To: <2649337.1188411092173.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15646708.1188498798458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1655?page=all ]

Chris Laprun updated JBPORTAL-1655:
-----------------------------------

    Component/s: Portal Core Admin
       Priority: Minor  (was: Major)

> Improve "rename" forms
> ----------------------
>
>                 Key: JBPORTAL-1655
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1655
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Thu Aug 30 15:34:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 15:34:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-413) Mavenize remoting
	project
Message-ID: <4072643.1188502459174.JavaMail.jira@cloud.prod.atl2.jboss.com>

Mavenize remoting project
-------------------------

                 Key: JBBUILD-413
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-413
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Remoting project needs to be properly mavenized so that app server builds can use 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 lists.jboss.org  Thu Aug 30 15:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1147) Release 4.0.1
	version
In-Reply-To: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25320087.1188503298655.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1147?page=all ]

Edson Tirelli updated JBRULES-1147:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Release 4.0.1 version
> ---------------------
>
>                 Key: JBRULES-1147
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.2
>
>
> Release 4.0.1 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 lists.jboss.org  Thu Aug 30 15:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1146) No variables are
 shown for Debug points
In-Reply-To: <25789503.1188441198879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9739660.1188503298830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1146?page=all ]

Edson Tirelli updated JBRULES-1146:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> No variables are shown for Debug points
> ---------------------------------------
>
>                 Key: JBRULES-1146
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1146
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg
>
>
> No variables are showing for break points.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24603452.1188503298999.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=all ]

Edson Tirelli updated JBRULES-1145:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23616517.1188503299165.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=all ]

Edson Tirelli updated JBRULES-1144:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1141) context assist no
 longer works for functions in the drl.
In-Reply-To: <17049984.1188270438381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5480440.1188503299357.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1141?page=all ]

Edson Tirelli updated JBRULES-1141:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> context assist no longer works for functions in the drl.
> --------------------------------------------------------
>
>                 Key: JBRULES-1141
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1141
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.2
>
>
> context assist no longer works for functions in the drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for nested expressions
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9370395.1188503299538.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1138?page=all ]

Edson Tirelli updated JBRULES-1138:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> MVEL code completion does not work for nested expressions
> ---------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1132) No code
 completion for 'from' expression statements
In-Reply-To: <28151937.1188060858274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8953197.1188503299718.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1132?page=all ]

Edson Tirelli updated JBRULES-1132:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> No code completion for 'from' expression statements
> ---------------------------------------------------
>
>                 Key: JBRULES-1132
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1132
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.2
>
>
> If I'm buliding a 'from' statement that is something like from $s.getItems() there is no code completion on that expression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5566527.1188503299892.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1124?page=all ]

Edson Tirelli updated JBRULES-1124:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.2
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:54:30 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 15:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-413) Mavenize remoting
	project
In-Reply-To: <4072643.1188502459174.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4430305.1188503670356.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-413?page=all ]

Paul Gier reassigned JBBUILD-413:
---------------------------------

    Assignee: Paul Gier

> Mavenize remoting project
> -------------------------
>
>                 Key: JBBUILD-413
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-413
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Remoting project needs to be properly mavenized so that app server builds can use 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 lists.jboss.org  Thu Aug 30 16:04:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 16:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1147) Release 4.0.1
	version
In-Reply-To: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6319502.1188504258372.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1147?page=all ]

Edson Tirelli closed JBRULES-1147.
----------------------------------

    Fix Version/s: 4.0.1
                       (was: 4.0.2)
       Resolution: Done

Released.

> Release 4.0.1 version
> ---------------------
>
>                 Key: JBRULES-1147
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Release 4.0.1 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 lists.jboss.org  Thu Aug 30 16:06:18 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 30 Aug 2007 16:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1285) portal
 testsuite report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8929686.1188504378322.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=comments#action_12374676 ] 
            
Prabhat Jha commented on JBPORTAL-1285:
---------------------------------------

With portal trunk, ant reports fails currently with CNFE for org.apache.tools.ant.taskdefs.optional.TraXLiaison. We need to put ant-trax.jar in tools/lib. 

> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 16:14:18 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 30 Aug 2007 16:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1285) portal
 testsuite report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24375105.1188504858298.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=comments#action_12374679 ] 
            
Prabhat Jha commented on JBPORTAL-1285:
---------------------------------------

After adding the jar, reports still fail with 

reports:
[junitreport] Processing C:\qa\portal-trunk\testsuite\output\reports\TESTS-TestSuites.xml to C:\DOCUME~1\pjha\LOCALS~1\Temp\null1132315364
[junitreport] Loading stylesheet jar:file:/C:/qa/portal-trunk/tools/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Failed to transform using stylesheet jar:file:/C:/qa/portal-trunk/tools/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Failed to process C:\qa\portal-trunk\testsuite\output\reports\TESTS-TestSuites.xml

BUILD FAILED
C:\qa\portal-trunk\testsuite\build.xml:172: Errors while applying transformations: C:\qa\portal-trunk\testsuite\build.xml:172: class org.apache.tools.ant.taskdefs.optional.TraXLiaison accepts the stylesheet only as a file


Since reports work with ant version that I have, can I go ahead and upload those?? Mine is 1.6.5.



> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 16:34:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 16:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-414) Mavenize security
	project
Message-ID: <22840794.1188506058257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Mavenize security project
-------------------------

                 Key: JBBUILD-414
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-414
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


The pom of the security project should be updated to fit project standards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 17:21:18 2007
From: jira-events at lists.jboss.org (Bhagwath Vadyala (JIRA))
Date: Thu, 30 Aug 2007 17:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1150) Drools 4.0 BRMS
 not working with geronimo-jetty6-jee5-2.0.1
Message-ID: <25850901.1188508878448.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools 4.0 BRMS not working with geronimo-jetty6-jee5-2.0.1
-----------------------------------------------------------

                 Key: JBRULES-1150
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1150
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
         Environment: geronimo-jetty6-jee5-2.0.1
drools-4.0.1.SNAPSHOT-brms
            Reporter: Bhagwath Vadyala
         Assigned To: Mark Proctor


I am trying to test and see whether Drools 4.0 BRMS works with Geronimo-jetty6-jee5-2.0.1 or not.

Drools BRMS version which I am using is drools-4.0.1.SNAPSHOT-brms.

It deploys fine in Geronimo but when I open the BRMS error message I am getting is HTTP ERROR:404.

Please let me know whether we can make Drools 4.0 work with Geronimo-jetty 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 lists.jboss.org  Thu Aug 30 17:32:18 2007
From: jira-events at lists.jboss.org (Bhagwath Vadyala (JIRA))
Date: Thu, 30 Aug 2007 17:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1150) Drools 4.0 BRMS
 not working with geronimo-jetty6-jee5-2.0.1
In-Reply-To: <25850901.1188508878448.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13863031.1188509538274.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1150?page=all ]

Bhagwath Vadyala updated JBRULES-1150:
--------------------------------------

    Component/s: drools-brms

> Drools 4.0 BRMS not working with geronimo-jetty6-jee5-2.0.1
> -----------------------------------------------------------
>
>                 Key: JBRULES-1150
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1150
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: geronimo-jetty6-jee5-2.0.1
> drools-4.0.1.SNAPSHOT-brms
>            Reporter: Bhagwath Vadyala
>         Assigned To: Mark Proctor
>
> I am trying to test and see whether Drools 4.0 BRMS works with Geronimo-jetty6-jee5-2.0.1 or not.
> Drools BRMS version which I am using is drools-4.0.1.SNAPSHOT-brms.
> It deploys fine in Geronimo but when I open the BRMS error message I am getting is HTTP ERROR:404.
> Please let me know whether we can make Drools 4.0 work with Geronimo-jetty 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 lists.jboss.org  Thu Aug 30 17:34:18 2007
From: jira-events at lists.jboss.org (Yuri de Wit (JIRA))
Date: Thu, 30 Aug 2007 17:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1151) Bulding sources
 from root folder fails
Message-ID: <14065664.1188509658255.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bulding sources from root folder fails
--------------------------------------

                 Key: JBRULES-1151
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1151
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions: 4.0.1
            Reporter: Yuri de Wit
         Assigned To: Mark Proctor


Tried to build from sources downloaded from the links provided in the mailing list and got the following (mvn package):

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).


Project ID: unknown

Reason: Could not find the model file 'C:\tools\drools-4.0.1\drools-ant\pom.xml'.


[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Could not find the model file 'C:\tools\drools-4.0.1\drools-ant\pom.xm
l'.
        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
        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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file 'C:\tools\drools-4.0.1\drool
s-ant\pom.xml'.
        at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1274)
        at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.ja
va:414)
        at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192)
        at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
        at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
        at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491)
        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
        ... 11 more
Caused by: java.io.FileNotFoundException: C:\tools\drools-4.0.1\drools-ant\pom.xml (The system cannot find the path spec
ified)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:106)
        at java.io.FileReader.<init>(FileReader.java:55)
        at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1269)
        ... 17 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Aug 30 17:28:45 EDT 2007
[INFO] Final Memory: 1M/3M
[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 lists.jboss.org  Thu Aug 30 17:38:18 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 30 Aug 2007 17:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1285) portal
 testsuite report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4655306.1188509898211.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=comments#action_12374694 ] 
            
Prabhat Jha commented on JBPORTAL-1285:
---------------------------------------

After adding ant-trax.jar with ant 1.7 and removing saxon and xalan jars from tools/lib, I am able to build portal trunk and run reports as well. I think parser or xsl xformer was getting used instead of that of xerces and that's where the problem was.

Is there a dependency on xalan or saxon jars. I am going to run full testsuite before I do a commit but please let me know if you can think of any problem.

These are the jars we need:

ant-junit.jar
ant-launcher.jar
ant-nodeps.jar
ant-trax.jar
ant.jar
bsf.jar
buildmagic-tasks.jar
cargo-core-uberjar-0.8.jar
crimson.jar
explode.jar
jboss-test.jar
jbossbuild.jar
junit.jar
xercesImpl.jar
xml-apis.jar


> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 18:05:18 2007
From: jira-events at lists.jboss.org (Steve Miner (JIRA))
Date: Thu, 30 Aug 2007 18:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1152) my unit tests are
 hanging with drools 4.0.1
Message-ID: <1213410.1188511518355.JavaMail.jira@cloud.prod.atl2.jboss.com>

my unit tests are hanging with drools 4.0.1
-------------------------------------------

                 Key: JBRULES-1152
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1152
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.1
         Environment: Java 1.5, Mac OX X 10.4.10, Drools 4.0.1
            Reporter: Steve Miner
         Assigned To: Mark Proctor


Sorry, I don't have very specific information.  Some of my project's unit tests are hanging with drools 4.0.1.  No error, just not completing.  I tried to debug a bit but could not figure it out.  Consider this an early warning until I can gather more info.

Everything worked fine with 4.0 so I went back to 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 lists.jboss.org  Thu Aug 30 18:20:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 18:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1654) Add separators
 on object
 pages to allow for better distinction between object and children
 operations
In-Reply-To: <20695198.1188410839568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13397947.1188512418183.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1654?page=all ]

Chris Laprun updated JBPORTAL-1654:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final
             Priority: Minor  (was: Major)

> Add separators on object pages to allow for better distinction between object and children operations
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1654
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1654
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Thu Aug 30 18:31:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 18:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1654) Add separators
 on object
 pages to allow for better distinction between object and children
 operations
In-Reply-To: <20695198.1188410839568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2638832.1188513078176.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1654?page=all ]

Chris Laprun resolved JBPORTAL-1654.
------------------------------------

    Resolution: Done

> Add separators on object pages to allow for better distinction between object and children operations
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1654
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1654
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:10:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1664)
 CurrentUserPortlet doesn't react to logouts properly
Message-ID: <27651586.1188519018568.JavaMail.jira@cloud.prod.atl2.jboss.com>

CurrentUserPortlet doesn't react to logouts properly
----------------------------------------------------

                 Key: JBPORTAL-1664
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1664
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Samples
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:24:22 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:24:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1665) Highlighting of
 currently selected range in pagination doesn't work properly
Message-ID: <30968748.1188519862544.JavaMail.jira@cloud.prod.atl2.jboss.com>

Highlighting of currently selected range in pagination doesn't work properly
----------------------------------------------------------------------------

                 Key: JBPORTAL-1665
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1665
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
            Priority: Minor
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:31:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1153)
 Accumulate/Collect can't be used in queries
Message-ID: <9910726.1188520278357.JavaMail.jira@cloud.prod.atl2.jboss.com>

Accumulate/Collect can't be used in queries
-------------------------------------------

                 Key: JBRULES-1153
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1153
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Mark Proctor



query "Count possible cell values"( $row, $col )
    # A superclass or interface can be used to match any derived classes
    $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
                                      count( $a ) )
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 lists.jboss.org  Thu Aug 30 20:31:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1153)
 Accumulate/Collect can't be used in queries
In-Reply-To: <9910726.1188520278357.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15645015.1188520278550.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1153?page=all ]

Edson Tirelli reassigned JBRULES-1153:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Accumulate/Collect can't be used in queries
> -------------------------------------------
>
>                 Key: JBRULES-1153
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1153
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.2
>
>
> query "Count possible cell values"( $row, $col )
>     # A superclass or interface can be used to match any derived classes
>     $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
>                                       count( $a ) )
> 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 lists.jboss.org  Thu Aug 30 20:31:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1153)
 Accumulate/Collect can't be used in queries
In-Reply-To: <9910726.1188520278357.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12486768.1188520278699.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1153?page=all ]

Edson Tirelli updated JBRULES-1153:
-----------------------------------

        Fix Version/s: 4.0.2
    Affects Version/s: 4.0.1
          Description: 
query "Count possible cell values"( $row, $col )
    # A superclass or interface can be used to match any derived classes
    $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
                                      count( $a ) )
end

  was:

query "Count possible cell values"( $row, $col )
    # A superclass or interface can be used to match any derived classes
    $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
                                      count( $a ) )
end


> Accumulate/Collect can't be used in queries
> -------------------------------------------
>
>                 Key: JBRULES-1153
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1153
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.2
>
>
> query "Count possible cell values"( $row, $col )
>     # A superclass or interface can be used to match any derived classes
>     $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
>                                       count( $a ) )
> 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 lists.jboss.org  Thu Aug 30 20:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1154)
 ClassCastException retrieving query parameters
Message-ID: <11704410.1188521298370.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassCastException retrieving query parameters
----------------------------------------------

                 Key: JBRULES-1154
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1154
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions: 4.0.1
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.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 lists.jboss.org  Thu Aug 30 20:50:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1588) Portlet
 instance list should
 "scroll" to the appropriate instance when a new instance is inserted in the
 list outside of the initial range
In-Reply-To: <20605356.1184641847020.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32280824.1188521418168.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1588?page=all ]

Chris Laprun resolved JBPORTAL-1588.
------------------------------------

    Resolution: Done

> Portlet instance list should "scroll" to the appropriate instance when a new instance is inserted in the list outside of the initial range
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1588
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1588
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6 Final, 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:50:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1665) Highlighting of
 currently selected range in pagination doesn't work properly
In-Reply-To: <30968748.1188519862544.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13232536.1188521418243.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1665?page=all ]

Chris Laprun resolved JBPORTAL-1665.
------------------------------------

    Resolution: Done
      Assignee: Chris Laprun

> Highlighting of currently selected range in pagination doesn't work properly
> ----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1665
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1665
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 22:13:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 30 Aug 2007 22:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1152) my unit tests
 are hanging with drools 4.0.1
In-Reply-To: <1213410.1188511518355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6193465.1188526398374.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12374708 ] 
            
Michael Neale commented on JBRULES-1152:
----------------------------------------

Waiting for more info (eg some sample code/rules to try out). 

I have access to a mac to try it out if you can provide it. 

> my unit tests are hanging with drools 4.0.1
> -------------------------------------------
>
>                 Key: JBRULES-1152
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1152
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>         Environment: Java 1.5, Mac OX X 10.4.10, Drools 4.0.1
>            Reporter: Steve Miner
>         Assigned To: Mark Proctor
>
> Sorry, I don't have very specific information.  Some of my project's unit tests are hanging with drools 4.0.1.  No error, just not completing.  I tried to debug a bit but could not figure it out.  Consider this an early warning until I can gather more info.
> Everything worked fine with 4.0 so I went back to 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 lists.jboss.org  Thu Aug 30 23:55:19 2007
From: jira-events at lists.jboss.org (Benjamin Madsen (JIRA))
Date: Thu, 30 Aug 2007 23:55:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-288) Fork/Join and child
 token deactivation
Message-ID: <12765489.1188532519077.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-288?page=comments#action_12374712 ] 
            
Benjamin Madsen commented on JBPM-288:
--------------------------------------

This seems to be a fairly old issue, however it is not fixed yet in the core.  Has there been any progress on this issue other than patching it ourselves?  Otherwise, is there a way around the problem that doesn't require patching the codebase?

> 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 lists.jboss.org  Fri Aug 31 03:00:28 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:00:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-763) Release 2.2.1.GA
In-Reply-To: <16838776.1183317717648.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28487731.1188543628320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-763?page=all ]

Ron Sigal closed JBREM-763.
---------------------------

    Resolution: Done

The jboss-remoting.jar file for this release was uploaded to the repository on July 1, 2007.

> Release 2.2.1.GA
> ----------------
>
>                 Key: JBREM-763
>                 URL: http://jira.jboss.com/jira/browse/JBREM-763
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.GA
>
>
> This release contains bug fixes for JBREM-747, JBREM-748, JBREM-751, and JBREM-761.  It is intended for inclusion with community JBossAS 4.2.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 lists.jboss.org  Fri Aug 31 03:04:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20125558.1188543858320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal reopened JBREM-779:
-----------------------------

             

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:04:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20611056.1188543858443.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal updated JBREM-779:
----------------------------

    Fix Version/s: 2.2.2.GA
                       (was: 2.2.1.SP1)

Fixed in Remoting 2.2.2.GA rather than 2.2.1.SP1.

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:04:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-779) BisocketClientInvoker
 should guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30676979.1188543858570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal closed JBREM-779.
---------------------------

    Resolution: Done

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:50:53 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 31 Aug 2007 03:50:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-288) Fork/Join and child
 token deactivation
Message-ID: <12176564.1188546653452.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-288?page=comments#action_12374720 ] 
            
Ronald van Kuijk commented on JBPM-288:
---------------------------------------

since it has no target, it can slip of the radar

> 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 lists.jboss.org  Fri Aug 31 03:50:53 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 03:50:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4214563.1188546653575.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374721 ] 
            
Carlo de Wolf commented on JBAS-4564:
-------------------------------------

java.lang.NoClassDefFoundError: org/hibernate/annotations/common/reflection/ReflectionManager
        at org.hibernate.ejb.Ejb3Configuration.<clinit>(Ejb3Configuration.java:105)
        at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:125)


> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:50:53 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 03:50:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21544760.1188546653742.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4564?page=all ]

Carlo de Wolf reassigned JBAS-4564:
-----------------------------------

    Assignee: Carlo de Wolf

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 04:18:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 04:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
Message-ID: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>

VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
----------------------------------------------------------------------

                 Key: JGRP-586
                 URL: http://jira.jboss.com/jira/browse/JGRP-586
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4.1 SP5, 2.5.1, 2.6


When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 04:40:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 31 Aug 2007 04:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19580449.1188549618333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]

Galder Zamarreno resolved JGRP-507.
-----------------------------------

    Fix Version/s: 2.4.1 SP3
                       (was: 2.6)
       Resolution: Done

Change in timer design as part of 2.4.1.SP3 fixed this.

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3 SP1, 2.2.9 SP4, 2.2.7 SP1, 2.4.1, 2.4.1 SP1, 2.4.1 SP2
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.4.1 SP3
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Fri Aug 31 04:57:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 04:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4634) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.0.SP4)
In-Reply-To: <21208408.1188210858201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14915445.1188550638217.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4634?page=comments#action_12374727 ] 
            
Dimitris Andreadis commented on JBAS-4634:
------------------------------------------

Onto 2.2.2.GA-brew.

> Upgrade jboss remoting to v2.2.2.GA (from v2.2.0.SP4)
> -----------------------------------------------------
>
>                 Key: JBAS-4634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4634
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Dimitris Andreadis
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Upgrade to latest remoting 2.2.2.GA when it becomes available.
> Upgraded to jboss remoting 2.2.1.GA in the meantime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:09:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 05:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4578) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.1.GA)
In-Reply-To: <27607751.1185302526035.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1138923.1188551358214.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4578?page=comments#action_12374728 ] 
            
Dimitris Andreadis commented on JBAS-4578:
------------------------------------------

Onto 2.2.2.GA-brew.

> Upgrade jboss remoting to v2.2.2.GA (from v2.2.1.GA)
> ----------------------------------------------------
>
>                 Key: JBAS-4578
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4578
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.2.2.GA
>
>
> There are some remoting fixes that justify a new remoting point release incorporated in JBossAS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:11:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 05:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
In-Reply-To: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1278556.1188551478208.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-586?page=comments#action_12374729 ] 
            
Bela Ban commented on JGRP-586:
-------------------------------

This issue does *not* exist in 2.4.x ! The reason it is in 2.5.x and CVS head is that I changed msg.putHeader(GMS.name, ...) to msg.putHeader(name) ! In the second case, name is "VIEW_SYNC", in the first it is "GMS" (which is correct).
So the fix applies only to 2.5 and CVS head (2.6)

> VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
> ----------------------------------------------------------------------
>
>                 Key: JGRP-586
>                 URL: http://jira.jboss.com/jira/browse/JGRP-586
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1, 2.4.1 SP5
>
>
> When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
> However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
> SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:13:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 05:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19748677.1188551598652.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374731 ] 
            
Dimitris Andreadis commented on JBAS-4564:
------------------------------------------

I saw the missing, 

    <componentref name="hibernate-commons-annotations" version="3.0.0.GA"/>    

Thanks Carlo.

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:15:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 05:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4634) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.0.SP4)
In-Reply-To: <21208408.1188210858201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16383218.1188551718227.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4634?page=all ]

Dimitris Andreadis reassigned JBAS-4634:
----------------------------------------

    Assignee: Dimitris Andreadis

> Upgrade jboss remoting to v2.2.2.GA (from v2.2.0.SP4)
> -----------------------------------------------------
>
>                 Key: JBAS-4634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4634
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Upgrade to latest remoting 2.2.2.GA when it becomes available.
> Upgraded to jboss remoting 2.2.1.GA in the meantime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 04:42:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 31 Aug 2007 04:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20586599.1188549738274.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]

Galder Zamarreno updated JGRP-507:
----------------------------------

    Fix Version/s: 2.5

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3 SP1, 2.2.9 SP4, 2.2.7 SP1, 2.4.1, 2.4.1 SP1, 2.4.1 SP2
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.5, 2.4.1 SP3
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Fri Aug 31 05:19:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 05:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
In-Reply-To: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25834761.1188551958261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-586?page=all ]

Bela Ban updated JGRP-586:
--------------------------

    Fix Version/s:     (was: 2.4.1 SP5)

Removed 2.4.x from fix dest

> VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
> ----------------------------------------------------------------------
>
>                 Key: JGRP-586
>                 URL: http://jira.jboss.com/jira/browse/JGRP-586
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>
> When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
> However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
> SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:19:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 05:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
In-Reply-To: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25637233.1188551958373.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-586?page=all ]

Bela Ban resolved JGRP-586.
---------------------------

    Resolution: Done

Fixed in 2.5 and 2.6

> VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
> ----------------------------------------------------------------------
>
>                 Key: JGRP-586
>                 URL: http://jira.jboss.com/jira/browse/JGRP-586
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
> However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
> SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:57:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 31 Aug 2007 05:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1666) When redploying,
 removed preferences in portlet-instances.xml are not deleted
Message-ID: <3657065.1188554238293.JavaMail.jira@cloud.prod.atl2.jboss.com>

When redploying, removed preferences in portlet-instances.xml are not deleted
-----------------------------------------------------------------------------

                 Key: JBPORTAL-1666
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1666
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final
            Reporter: Thomas Heute
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 Final


with <if-exists>overwrite</if-exists> if someone have a preference in portlet-instances.xml, then remove that preference and redeploy . It won't be reflected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:59:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 31 Aug 2007 05:59:18 -0400 (EDT)
Subject: [jboss-jira] 
 [JBoss JIRA] Resolved: (JBPORTAL-1666) When redploying, removed
 preferences in portlet-instances.xml are not deleted
In-Reply-To: <3657065.1188554238293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23838218.1188554358195.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1666?page=all ]

Thomas Heute resolved JBPORTAL-1666.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

> When redploying, removed preferences in portlet-instances.xml are not deleted
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1666
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1666
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> with <if-exists>overwrite</if-exists> if someone have a preference in portlet-instances.xml, then remove that preference and redeploy . It won't be reflected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:05:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 06:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4654) JacORB throwing
 spurious UNKNOWN NoSuchMethodException
Message-ID: <27298286.1188554718519.JavaMail.jira@cloud.prod.atl2.jboss.com>

JacORB throwing spurious UNKNOWN NoSuchMethodException
------------------------------------------------------

                 Key: JBAS-4654
                 URL: http://jira.jboss.com/jira/browse/JBAS-4654
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: IIOP service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
         Assigned To: Francisco Reverbel
             Fix For: JBossAS-5.0.0.GA


When a RemoteException contains an exception that isn't mapped to a CorbaException,
JacORB is throwing a spurious NoSuchMethodException.

e.g. the following error thrown by the server in the testsuite:

2007-08-31 11:42:48,113 TRACE [org.jboss.proxy.ejb.EjbObjectCorbaServant.bank-iiop/Account] Exception in EJBObject invocation
javax.management.MBeanException
        at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
        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.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:287)
        at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
        at org.jacorb.poa.RequestProcessor.process(Unknown Source)
        at org.jacorb.poa.RequestProcessor.run(Unknown Source)
Caused by: java.rmi.ServerException: EJBException:; nested exception is: 
        javax.ejb.EJBException: Internal error getting results for field member owner
        at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:365)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
        at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:532)
        at org.jboss.ejb.Container.invoke(Container.java:989)
        at sun.reflect.GeneratedMethodAccessor97.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:157)
        ... 8 more
Caused by: javax.ejb.EJBException: Internal error getting results for field member owner
        at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:498)
        at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:432)
        at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:393)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
        at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
        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:280)
        at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
        at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
        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:350)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:238)
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:105)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
        ... 15 more
Caused by: java.sql.SQLException: Got a org.omg.stub.javax.ejb._EJBObject_Stub[cl=org.jboss.mx.loading.UnifiedClassLoader3 at ff45de{ url=vfsfile:/home/ejort/jboss-head/b

Results in the following on the client:

"CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExcept
ion: CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
        at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
        at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
        at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
        at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
        at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source)
        at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
        at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
        at org.jacorb.orb.Delegate.invoke(Unknown Source)
        at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)
        ... 23 more
Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.&lt;init&gt;(java.lang.String, int, org.omg.CORBA.CompletionStatus)
        at java.lang.Class.getConstructor0(Class.java:2678)
        at java.lang.Class.getConstructor(Class.java:1629)
        ... 29 more

The NoSuchMethodException is obviously not the cause.
It comes from jacorb assuming that all Corba SystemExceptions have a constructor of a certain signature
(something that is not true for UnknownException).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:07:25 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 06:07:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4654) JacORB throwing
 spurious UNKNOWN NoSuchMethodException
In-Reply-To: <27298286.1188554718519.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13816685.1188554845875.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4654?page=all ]

Adrian Brock updated JBAS-4654:
-------------------------------

    Attachment: SystemExceptionHelper.java

Attached is an updated version of JacORB's SystemExceptionHelper
that at least removes the spurious NoSuchMethodException.

It basically adds:

        catch (NoSuchMethodException e)

        {
            return (org.omg.CORBA.SystemException) new org.omg.CORBA.UNKNOWN(className + ": " + message);
        }

And produces output like the following.

CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException:   vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExce
ption: CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException:   vmcid: 0x0  minor code: 0  completed: No
        at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
        at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
        at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
        at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException:   vmcid: 0x0  minor code: 0  completed: No
        at org.jacorb.orb.SystemExceptionHelper.read(SystemExceptionHelper.java:230)
        at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
        at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
        at org.jacorb.orb.Delegate.invoke(Unknown Source)
        at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)


> JacORB throwing spurious UNKNOWN NoSuchMethodException
> ------------------------------------------------------
>
>                 Key: JBAS-4654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4654
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-5.0.0.GA
>
>         Attachments: SystemExceptionHelper.java
>
>
> When a RemoteException contains an exception that isn't mapped to a CorbaException,
> JacORB is throwing a spurious NoSuchMethodException.
> e.g. the following error thrown by the server in the testsuite:
> 2007-08-31 11:42:48,113 TRACE [org.jboss.proxy.ejb.EjbObjectCorbaServant.bank-iiop/Account] Exception in EJBObject invocation
> javax.management.MBeanException
>         at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
>         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.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:287)
>         at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.process(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.run(Unknown Source)
> Caused by: java.rmi.ServerException: EJBException:; nested exception is: 
>         javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:365)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:532)
>         at org.jboss.ejb.Container.invoke(Container.java:989)
>         at sun.reflect.GeneratedMethodAccessor97.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:157)
>         ... 8 more
> Caused by: javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:498)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:432)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:393)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
>         at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
>         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:280)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
>         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:350)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:238)
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:105)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         ... 15 more
> Caused by: java.sql.SQLException: Got a org.omg.stub.javax.ejb._EJBObject_Stub[cl=org.jboss.mx.loading.UnifiedClassLoader3 at ff45de{ url=vfsfile:/home/ejort/jboss-head/b
> Results in the following on the client:
> "CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExcept
> ion: CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
>         at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
>         at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
>         at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>         at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source)
>         at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke(Unknown Source)
>         at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)
>         ... 23 more
> Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.&lt;init&gt;(java.lang.String, int, org.omg.CORBA.CompletionStatus)
>         at java.lang.Class.getConstructor0(Class.java:2678)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         ... 29 more
> The NoSuchMethodException is obviously not the cause.
> It comes from jacorb assuming that all Corba SystemExceptions have a constructor of a certain signature
> (something that is not true for UnknownException).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:09:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 06:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4654) JacORB throwing
 spurious UNKNOWN NoSuchMethodException
In-Reply-To: <27298286.1188554718519.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18983320.1188554958397.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4654?page=comments#action_12374737 ] 
            
Adrian Brock commented on JBAS-4654:
------------------------------------

On a related issue, it would nice if there was someway to pass the "message" back to the client
for the UnknownExceptions?

i.e. the
java.rmi.ServerException: EJBException:; nested exception is:  javax.ejb.EJBException: Internal error getting results for field member owner

etc.

> JacORB throwing spurious UNKNOWN NoSuchMethodException
> ------------------------------------------------------
>
>                 Key: JBAS-4654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4654
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-5.0.0.GA
>
>         Attachments: SystemExceptionHelper.java
>
>
> When a RemoteException contains an exception that isn't mapped to a CorbaException,
> JacORB is throwing a spurious NoSuchMethodException.
> e.g. the following error thrown by the server in the testsuite:
> 2007-08-31 11:42:48,113 TRACE [org.jboss.proxy.ejb.EjbObjectCorbaServant.bank-iiop/Account] Exception in EJBObject invocation
> javax.management.MBeanException
>         at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
>         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.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:287)
>         at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.process(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.run(Unknown Source)
> Caused by: java.rmi.ServerException: EJBException:; nested exception is: 
>         javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:365)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:532)
>         at org.jboss.ejb.Container.invoke(Container.java:989)
>         at sun.reflect.GeneratedMethodAccessor97.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:157)
>         ... 8 more
> Caused by: javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:498)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:432)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:393)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
>         at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
>         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:280)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
>         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:350)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:238)
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:105)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         ... 15 more
> Caused by: java.sql.SQLException: Got a org.omg.stub.javax.ejb._EJBObject_Stub[cl=org.jboss.mx.loading.UnifiedClassLoader3 at ff45de{ url=vfsfile:/home/ejort/jboss-head/b
> Results in the following on the client:
> "CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExcept
> ion: CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
>         at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
>         at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
>         at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>         at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source)
>         at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke(Unknown Source)
>         at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)
>         ... 23 more
> Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.&lt;init&gt;(java.lang.String, int, org.omg.CORBA.CompletionStatus)
>         at java.lang.Class.getConstructor0(Class.java:2678)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         ... 29 more
> The NoSuchMethodException is obviously not the cause.
> It comes from jacorb assuming that all Corba SystemExceptions have a constructor of a certain signature
> (something that is not true for UnknownException).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:30:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
Message-ID: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problems for connecting a Weblogic 10 Portal WSRP Producer
----------------------------------------------------------

                 Key: JBPORTAL-1667
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.6.1 Final, 2.6 Final
         Environment: Microsoft Windows 2000
Sun JDK 1.5.06
JBoss Portal 2.6.1 Final
JBoss Portal 2.6 Final
            Reporter: Mehmet Salgar
         Assigned To: Chris Laprun


I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 

'ERROR [CallImpl] Call invocation failed with SOAPFaultException
javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
        java.lang.NumberFormatException: null'

I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.

When I try to connect from WSRP Admin portlet to the WSDL URL I am getting this exception.

Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.

Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.

I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.

The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.

Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.

I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:32:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17069802.1188556338347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Mehmet Salgar updated JBPORTAL-1667:
------------------------------------

    Description: 
I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 

'ERROR [CallImpl] Call invocation failed with SOAPFaultException
javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
        java.lang.NumberFormatException: null'

I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.

When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.

Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.

Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.

I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.

The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.

Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.

I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

  was:
I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 

'ERROR [CallImpl] Call invocation failed with SOAPFaultException
javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
        java.lang.NumberFormatException: null'

I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.

When I try to connect from WSRP Admin portlet to the WSDL URL I am getting this exception.

Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.

Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.

I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.

The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.

Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.

I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.


> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>         Attachments: myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:32:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9820557.1188556338546.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Mehmet Salgar updated JBPORTAL-1667:
------------------------------------

    Attachment: myPortalEAR.ear

> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>         Attachments: myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:34:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9973629.1188556458266.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Mehmet Salgar updated JBPORTAL-1667:
------------------------------------

    Attachment: fullstacktrace.txt

> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>         Attachments: fullstacktrace.txt, myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:40:25 2007
From: jira-events at lists.jboss.org (Mircea Markus (JIRA))
Date: Fri, 31 Aug 2007 06:40:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1154) Introduce ability
 to mark
 nodes as resident- i.e., they never get considered for eviction
In-Reply-To: <19979184.1185539627066.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5746725.1188556825312.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1154?page=all ]

Mircea Markus updated JBCACHE-1154:
-----------------------------------

    Summary: Introduce ability to mark nodes as resident- i.e., they never get considered for eviction  (was: Introduce ability to mark nodes as immortal - i.e., they never get considered for eviction)

resident is a name that fits better than immortal - after all the nodes can be removed, but are not counted by eviction policies

> Introduce ability to mark nodes as resident- i.e., they never get considered for eviction
> -----------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 07:21:18 2007
From: jira-events at lists.jboss.org (Thomas Hehl (JIRA))
Date: Fri, 31 Aug 2007 07:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1155) In Decision Table
 actions, cannot reference variables that were not referenced in LHS
Message-ID: <1012264.1188559278297.JavaMail.jira@cloud.prod.atl2.jboss.com>

In Decision Table actions, cannot reference variables that were not referenced in LHS
-------------------------------------------------------------------------------------

                 Key: JBRULES-1155
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1155
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
    Affects Versions: 4.0.1
         Environment: Windows
            Reporter: Thomas Hehl
         Assigned To: Mark Proctor
            Priority: Minor


If I use a decision table to build rules for my application, there doesn't appear to be a way to store an answer on a variable that wasn't referenced in the LHS of the rule. This is because the reference to the object that must be built can only be defined in the LHS.

I would like to be able to directly reference these "catcher" objects from the action to store the result even if they were not needed as part of the LHS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:01:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
Message-ID: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>

Suppling a RemoteHome or LocalHome is not registered
----------------------------------------------------

                 Key: EJBTHREE-1041
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:01:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
In-Reply-To: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17142915.1188561678507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1041?page=all ]

Carlo de Wolf reassigned EJBTHREE-1041:
---------------------------------------

    Assignee: Carlo de Wolf

> Suppling a RemoteHome or LocalHome is not registered
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1041
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:03:34 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:03:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
In-Reply-To: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5765254.1188561814161.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1041?page=all ]

Carlo de Wolf updated EJBTHREE-1041:
------------------------------------

    Fix Version/s: EJB 3.0 RC11 - FD
      Description: When a bean declares a RemoteHome or LocalHome the interface is not registered in MC as a supply.
         Priority: Critical  (was: Major)

> Suppling a RemoteHome or LocalHome is not registered
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1041
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - FD
>
>
> When a bean declares a RemoteHome or LocalHome the interface is not registered in MC as a supply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:13:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
In-Reply-To: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26122075.1188562398219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1041?page=all ]

Carlo de Wolf resolved EJBTHREE-1041.
-------------------------------------

    Resolution: Done

> Suppling a RemoteHome or LocalHome is not registered
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1041
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - FD
>
>
> When a bean declares a RemoteHome or LocalHome the interface is not registered in MC as a supply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:41:22 2007
From: jira-events at lists.jboss.org (Mircea Markus (JIRA))
Date: Fri, 31 Aug 2007 08:41:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1154) Introduce
 ability to mark
 nodes as resident- i.e., they never get considered for eviction
In-Reply-To: <19979184.1185539627066.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18787125.1188564082847.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1154?page=comments#action_12374743 ] 
            
Mircea Markus commented on JBCACHE-1154:
----------------------------------------

created topic on design forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=207
Steve - any feedback extremely welcomed!


> Introduce ability to mark nodes as resident- i.e., they never get considered for eviction
> -----------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 08:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
In-Reply-To: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32775322.1188564499104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1149?page=all ]

Edson Tirelli reopened JBRULES-1149:
------------------------------------

             
Reopening. Problem still persists.

> Parser is only saving last CE for prefixed AND/OR 
> --------------------------------------------------
>
>                 Key: JBRULES-1149
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Reported by user:
> Hi,
> I have a problem with this execution :
> rule "Your First Rule"
> when
>  (or
>  not Venue()
>  (and v:Venue()
>        l:ListeSousVenue()
>        p:Param()))
> then
>  System.out.println("OK - 1");
> end
> rule "Your Second Rule"
> when
>  (or
>  not Venue()
>  (and p:Param()
>        l:ListeSousVenue()
>        v:Venue()))
> then
>    System.out.println("OK - 2");
> end
> In my WM, I have a Param and a ListeSousVenue but no Venue
> But after execution, I have just this result :
> "OK - 1"
> Why the second rule doesn't execute ?
> Thanks,
> Vdelbart

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:58:29 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
In-Reply-To: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19880252.1188565109524.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1149?page=all ]

Edson Tirelli closed JBRULES-1149.
----------------------------------

    Resolution: Done

It was fixed. Problem is in file logger.

> Parser is only saving last CE for prefixed AND/OR 
> --------------------------------------------------
>
>                 Key: JBRULES-1149
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Reported by user:
> Hi,
> I have a problem with this execution :
> rule "Your First Rule"
> when
>  (or
>  not Venue()
>  (and v:Venue()
>        l:ListeSousVenue()
>        p:Param()))
> then
>  System.out.println("OK - 1");
> end
> rule "Your Second Rule"
> when
>  (or
>  not Venue()
>  (and p:Param()
>        l:ListeSousVenue()
>        v:Venue()))
> then
>    System.out.println("OK - 2");
> end
> In my WM, I have a Param and a ListeSousVenue but no Venue
> But after execution, I have just this result :
> "OK - 1"
> Why the second rule doesn't execute ?
> Thanks,
> Vdelbart

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:58:29 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1156)
 WorkingMemoryFileLogger is
 raising NPE for rules containing unbalanced OR CEs
Message-ID: <22151416.1188565109632.JavaMail.jira@cloud.prod.atl2.jboss.com>

WorkingMemoryFileLogger is raising NPE for rules containing unbalanced OR CEs
-----------------------------------------------------------------------------

                 Key: JBRULES-1156
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1156
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions: 4.0.1
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.2


Apply WorkingMemoryFileLogger for rules like the following and it will raise the NPE:

rule "Your First Rule"
	#include attributes such as "salience" here...
	when
		(or
		 not Venue()
		(and v:Venue()
		  l:ListeSousVenue()
		  p:Param()))
	then 
		#actions
		System.out.println("OK - 1");
end
rule "Your Second Rule"
	#include attributes such as "salience" here...
	when
		(or
		 not Venue()
		(and p:Param()
		     l:ListeSousVenue()
		     v:Venue()))
	then 
		#actions
		System.out.println("OK - 2");
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 lists.jboss.org  Fri Aug 31 09:02:18 2007
From: jira-events at lists.jboss.org (Markus Fromme (JIRA))
Date: Fri, 31 Aug 2007 09:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1157) threads using one
 ruleset throws exception
Message-ID: <23447978.1188565338418.JavaMail.jira@cloud.prod.atl2.jboss.com>

threads using one ruleset throws exception
------------------------------------------

                 Key: JBRULES-1157
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1157
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.1
         Environment: Windows XP, Eclipse 3.2
            Reporter: Markus Fromme
         Assigned To: Mark Proctor
            Priority: Critical


one ruleset for two threads using their own statefulsession and data results in this error:

Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:08:18 2007
From: jira-events at lists.jboss.org (Markus Fromme (JIRA))
Date: Fri, 31 Aug 2007 09:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1157) threads using one
 ruleset throws exception
In-Reply-To: <23447978.1188565338418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25917263.1188565698581.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1157?page=all ]

Markus Fromme updated JBRULES-1157:
-----------------------------------

    Description: 
one ruleset for two threads using their own statefulsession and data results in this error:

Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)
Exception in thread "Thread-0" java.lang.NullPointerException
	at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:220)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:158)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)


  was:
one ruleset for two threads using their own statefulsession and data results in this error:

Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)


> threads using one ruleset throws exception
> ------------------------------------------
>
>                 Key: JBRULES-1157
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1157
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Markus Fromme
>         Assigned To: Mark Proctor
>            Priority: Critical
>
> one ruleset for two threads using their own statefulsession and data results in this error:
> Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
> 	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
> 	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
> 	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
> 	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
> 	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
> 	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
> 	at eu.cewe.drools.Client.run(Client.java:22)
> Exception in thread "Thread-0" java.lang.NullPointerException
> 	at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:220)
> 	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:158)
> 	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
> 	at eu.cewe.drools.Client.run(Client.java:22)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:08:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 09:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-585) FD_SOCK: make
 fetching of cache asynchronous
In-Reply-To: <29535831.1188476178345.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6421739.1188565698697.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-585?page=all ]

Bela Ban resolved JGRP-585.
---------------------------

    Resolution: Done

Tested with JGroups/doc/tests/ManualTests.txt, passed

> FD_SOCK: make fetching of cache asynchronous
> --------------------------------------------
>
>                 Key: JGRP-585
>                 URL: http://jira.jboss.com/jira/browse/JGRP-585
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> FD_SOCK fetches the cache *synchronously* on down(VIEW_CHANGE). This blocks until the cache has been received, blocking down() and therefore other down calls. This could for example block a JOIN_RSP to a new joiner, causing the JOIN_REQ to fail.
> [Vladimir]
> Trying to dig into the trenches in order to understand why exactly is ConcurrentStartupTest failing if we switch up and down view sending in GMS#installView! I noticed that FD_SOCK in down for VIEW_CHANGE event does a very unusual thing: synchronous mcast invocation and it does it repeatedly until succeeds in getting cache contents or timeouts. But it does not look like it is 100% necessary to do this? Can't we abstract getting cache contents into a task that is run on a timer until we get a result? So we effectively we make getting cache contents asynchronous that does not potentially block view installation for quite a while because as it is now - this is what is happening.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:08:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 09:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1154) ClassCastException
 retrieving query parameters
In-Reply-To: <11704410.1188521298370.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27266388.1188565698826.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1154?page=all ]

Edson Tirelli closed JBRULES-1154.
----------------------------------

    Resolution: Done

Fixed

> ClassCastException retrieving query parameters
> ----------------------------------------------
>
>                 Key: JBRULES-1154
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1154
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions: 4.0.1
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.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 lists.jboss.org  Fri Aug 31 09:26:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Fri, 31 Aug 2007 09:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9058949.1188566778268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374756 ] 
            
Emmanuel Bernard commented on JBAS-4564:
----------------------------------------

Yes hibernate-commons-annotations is required.
Another problem may arise. Hibernate Validator (the component) is now separate from hibernate-annotations
Do we consider it part of the JBoss AS distro, or is it safe to not include it (ie let the user add it if needed)?

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:28:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 31 Aug 2007 09:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4455) LoadBalancePolicy
 that tries to pin all requests associated with a tx to one server
In-Reply-To: <14717863.1180632608477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26062394.1188566898326.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4455?page=all ]

Galder Zamarreno updated JBAS-4455:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117013

> LoadBalancePolicy that tries to pin all requests associated with a tx to one server
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-4455
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4455
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> The HA proxies don't allow failover once a tx has reached a server.  This can lead to this kind of situation:
> EJB A deployed on nodes 1 and 2.
> EJB B deployed on nodes 1 and 2.
> 1) Start tx, invoke on A.1.
> 2) Lookup B.
> 3) Invoke on B. LB policy picks B.2
> 4) Node 2 is dead for some reason so call fails.
> 5) Can't fail over because tx context won't allow a failover after a call has reached a server.
> But, B.1 is fine and is running on the only node the tx has invoked on. :(
> Approach to improving this.  This is based on JRMPInovkerProxyHA methods, but the idea is generic:
> In invocationHasReachedAServer, instead of storing null as the value, you store the target (key is the tx).
> In invoke, if there's a tx, you add that target (if there is one) to the invocation as transient metadata 
> The LB policy gets passed the invocation as an arg when it chooses a target (this is already in the API)
> LB policy checks for the metadata. If there, and that target is in its target list, return that target

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:05:52 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 10:05:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1668) A user with
 "Administrator"
 privileges is not able to create resources at the root level of the CMS
 repo
Message-ID: <22525764.1188569152087.JavaMail.jira@cloud.prod.atl2.jboss.com>

A user with "Administrator" privileges is not able to create resources at the root level of the CMS repo
--------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1668
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1668
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.6.1 Final, 2.6 Final, 2.6 CR3, 2.6.CR1, 2.6.CR2, 2.6.Beta1, 2.6.Alpha2, 2.6.Alpha1
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 2.6.2 Final


How to reproduce-

Assign a Portal user to Administrator group. Login as this user, and try to create a Folder at "/" path of the CMS repo.

You get an Access Denied 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 lists.jboss.org  Fri Aug 31 10:09:25 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 10:09:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23527675.1188569365946.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374767 ] 
            
Dimitris Andreadis commented on JBAS-4564:
------------------------------------------

I don't think it would make harm if we include it, as it was implicitly included before.

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:21:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Aug 2007 10:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1063) MessageID
 changes when the message is transfered over the cluster.
Message-ID: <22046415.1188570078656.JavaMail.jira@cloud.prod.atl2.jboss.com>

MessageID changes when the message is transfered over the cluster.
------------------------------------------------------------------

                 Key: JBMESSAGING-1063
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1063
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR2
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:45:19 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Fri, 31 Aug 2007 10:45:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-14) Lay out Algorithm
In-Reply-To: <763449.1168949213846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12526320.1188571519076.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-14?page=comments#action_12374783 ] 
            
Matthew Sandoz commented on GPD-14:
-----------------------------------

I'm looking at creating an implementation of this feature that pulls the graph structure into another package that does layouts and then generating move commands. Is that a viable approach or is there a specific set of algorithms you'd need to use? I would then simply include a button or menu item to apply the layout(s). I may have some time over the next month or so to put it together.


> Lay out Algorithm
> -----------------
>
>                 Key: GPD-14
>                 URL: http://jira.jboss.com/jira/browse/GPD-14
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Integrate a layout algorithm that is used when users add nodes to the xml directly to lay out the newly created components in an orderly fashion on the graphical canvas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:49:29 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 10:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3589940.1188571769767.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=comments#action_12374784 ] 
            
Chris Laprun commented on JBPORTAL-1667:
----------------------------------------

"The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem. Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves."

Why do you assume that it's JBoss Portal's fault? I could make modifications to both our consumer and producer in such a way that it would not be conform to the specification and yet work perfectly well with each other but break with every other products out there... The fact that WLP works with itself is not conclusive evidence that its implementation is correct.

That said I will look into the problem. Could you please attach the ServiceDescription sent by WLP 10?




> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: fullstacktrace.txt, myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:49:29 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 10:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25908110.1188571769907.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Chris Laprun updated JBPORTAL-1667:
-----------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final

> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: fullstacktrace.txt, myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:57:18 2007
From: jira-events at lists.jboss.org (Fernando Nasser (JIRA))
Date: Fri, 31 Aug 2007 10:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4148) Replace Gjt code
 used in the ejb 2.x validation phase
In-Reply-To: <23704302.1172165075447.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6646524.1188572238321.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4148?page=all ]

Fernando Nasser reassigned JBAS-4148:
-------------------------------------

    Assignee: Juha Lindfors

Can you help us with this?

> Replace Gjt code used in the ejb 2.x validation phase
> -----------------------------------------------------
>
>                 Key: JBAS-4148
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4148
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Fernando Nasser
>         Assigned To: Juha Lindfors
>             Fix For: JBossAS-4.2.2.GA
>
>
> The JBossAS thirdpart-build.xml grabs a
> <componentref name="gjt-jpl-util" version="1.0"/>
> from repository.jboss.com
> However, the Gjt project has never released a 1.0 version, only a 0.6 version for the Linffors utils and the jpl_util_0_6 is the only tag in their CVS.
> So, what is the meaning for version 1.0?  The CVS tip?
> Also, what is marked as gjt-jpl-util also contains gjt-jpl-pattern, and the latest CVS tag for that is:
> jpl-pattern_0_3_b    (0.3 beta perhaps)
> Besides, there is a warning in the pattern source directory:
> "Untagged files may be (and probably are) in an unstable state and might not
> compile. If you want something that works, checkout with tags. You have been
> warned. :)  -- Juha" 
> Here, for the record, is Scott's opinion:
> Scott M Stark wrote:
> > This is some ancient code used only in the ejb 2.x validation phase. It
> > has not been touched in something like 5 years. Either we need to
> > replace it or pull together some code that makes up a usable 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 lists.jboss.org  Fri Aug 31 11:22:34 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 11:22:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4655) HandleImplIIOP not
 retrieving EJBObject correctly
Message-ID: <7109367.1188573754351.JavaMail.jira@cloud.prod.atl2.jboss.com>

HandleImplIIOP not retrieving EJBObject correctly
-------------------------------------------------

                 Key: JBAS-4655
                 URL: http://jira.jboss.com/jira/browse/JBAS-4655
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: IIOP service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


The IIOP tests in JBoss Head are failing because the
HandleImplIIOP.getEJBObject()
is returning a stub only for EJBObject and not for the business interface.

The test should also be failing in jboss-4.2 but the test isn't failing because
it is using commit option A and thus not reloading from the database.

I'm going to change the bankiiop stress test in jboss-4.2 to use "instance per transaction" to show the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:32:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 11:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4655) HandleImplIIOP not
 retrieving EJBObject correctly
In-Reply-To: <7109367.1188573754351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20996079.1188574338202.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4655?page=comments#action_12374797 ] 
            
Adrian Brock commented on JBAS-4655:
------------------------------------

The reason why the test is failing is because HandleImplIIOP is doing

PortableRemoteObject.narrow(CorbaORB.getInstance().string_to_object(ior), EJBObject.class);

PortableRemoteObject.narrow()
tests whether the object implements the class
if it does not, it "generates" the stub from the passed class.

In jacorb's case, string.to_object(ior) returns an org.jacorb.orb.Reference

> HandleImplIIOP not retrieving EJBObject correctly
> -------------------------------------------------
>
>                 Key: JBAS-4655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4655
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> The IIOP tests in JBoss Head are failing because the
> HandleImplIIOP.getEJBObject()
> is returning a stub only for EJBObject and not for the business interface.
> The test should also be failing in jboss-4.2 but the test isn't failing because
> it is using commit option A and thus not reloading from the database.
> I'm going to change the bankiiop stress test in jboss-4.2 to use "instance per transaction" to show the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:49:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1063) MessageID
 changes when the message is transfered over the cluster.
In-Reply-To: <22046415.1188570078656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11625662.1188575358797.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1063?page=all ]

Clebert Suconic updated JBMESSAGING-1063:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117536

> MessageID changes when the message is transfered over the cluster.
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1063
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1063
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:49:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Aug 2007 11:49:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1063) MessageID
 changes when the message is transfered over the cluster.
In-Reply-To: <22046415.1188570078656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32285581.1188575359111.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1063?page=all ]

Clebert Suconic closed JBMESSAGING-1063.
----------------------------------------

    Resolution: Done

> MessageID changes when the message is transfered over the cluster.
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1063
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1063
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:53:18 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Fri, 31 Aug 2007 11:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-587) Lightweight FLUSH for
 state transfer
Message-ID: <33510599.1188575598551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lightweight FLUSH for state transfer
------------------------------------

                 Key: JGRP-587
                 URL: http://jira.jboss.com/jira/browse/JGRP-587
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.7


We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:09:18 2007
From: jira-events at lists.jboss.org (Michael Small (JIRA))
Date: Fri, 31 Aug 2007 12:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJMX-108) Provide JAAS
 credentials in
 org.jboss.ant.JMX task so that calls can be made to security protected
 MBeans.
Message-ID: <3443802.1188576558213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide JAAS credentials in org.jboss.ant.JMX task so that calls can be made to security protected MBeans.
----------------------------------------------------------------------------------------------------------

                 Key: JBJMX-108
                 URL: http://jira.jboss.com/jira/browse/JBJMX-108
             Project: JBoss JMX
          Issue Type: Feature Request
            Reporter: Michael Small


I have MBeans (using the @Security and @Management annotations) that are associated with a security domain.  It would great if the JBoss JMX Ant Task was enhanced to accept a username and password for JAAS security.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:11:19 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Fri, 31 Aug 2007 12:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-1285) portal testsuite
 report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13314466.1188576679250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=all ]

Prabhat Jha closed JBPORTAL-1285.
---------------------------------

    Resolution: Done

I just did a complete build and ran the whole testsuite with ant in tools/lib. trunk/buid/build.bat and trunk/testsuiste/build.bat tests/reports

> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:23:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 31 Aug 2007 12:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-415) Add a feature to
 dependency plugin to find conflicting versions
Message-ID: <31981849.1188577398230.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a feature to dependency plugin to find conflicting versions
---------------------------------------------------------------

                 Key: JBBUILD-415
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-415
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: Maven
    Affects Versions: Maven Build - Maint 2007
            Reporter: Paul Gier


Add a feature to the maven dependency plugin that finds if a dependency tree contains two different versions of the same artifact.
This could be an additional section in the results of the analyze goal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:25:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 31 Aug 2007 12:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-415) Add a feature to
 dependency plugin to find conflicting versions
In-Reply-To: <31981849.1188577398230.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1293297.1188577518254.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-415?page=all ]

Paul Gier updated JBBUILD-415:
------------------------------

        Fix Version/s: Maven Build - Maint 2007
    Affects Version/s:     (was: Maven Build - Maint 2007)

> Add a feature to dependency plugin to find conflicting versions
> ---------------------------------------------------------------
>
>                 Key: JBBUILD-415
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-415
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Add a feature to the maven dependency plugin that finds if a dependency tree contains two different versions of the same artifact.
> This could be an additional section in the results of the analyze goal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 14:32:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 31 Aug 2007 14:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1175)
	Option.forceCall(A)sync
Message-ID: <31286648.1188585138477.JavaMail.jira@cloud.prod.atl2.jboss.com>

Option.forceCall(A)sync
-----------------------

                 Key: JBCACHE-1175
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1175
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
             Fix For: 2.1.0.GA


Add an option to allow an individual call to go async/sync when the cache overall is configured for the opposite.

This would only be relevant to calls not running in a tx; transactional replication would use the standard semantic configured for the cache.

Use case for this is Hibernate timestamp region replication, which needs to go async, while all other Hibernate 2nd level cache traffic goes sync.  A good region-based cache impl would solve the problem as well, but that will surely take quite a while to implement a while while doing it via an Option looks quite 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 lists.jboss.org  Fri Aug 31 14:32:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 31 Aug 2007 14:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1175)
	Option.forceCall(A)sync
In-Reply-To: <31286648.1188585138477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12812172.1188585138705.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=comments#action_12374821 ] 
            
Brian Stansberry commented on JBCACHE-1175:
-------------------------------------------

Manik, I left this assigned to you in order to get your input, but if you think it's OK to do, feel free to assign back to me.

> Option.forceCall(A)sync
> -----------------------
>
>                 Key: JBCACHE-1175
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1175
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Add an option to allow an individual call to go async/sync when the cache overall is configured for the opposite.
> This would only be relevant to calls not running in a tx; transactional replication would use the standard semantic configured for the cache.
> Use case for this is Hibernate timestamp region replication, which needs to go async, while all other Hibernate 2nd level cache traffic goes sync.  A good region-based cache impl would solve the problem as well, but that will surely take quite a while to implement a while while doing it via an Option looks quite 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 lists.jboss.org  Fri Aug 31 15:37:18 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 31 Aug 2007 15:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-456) Create annotations
 correpondent to xml tags
Message-ID: <10621792.1188589038704.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create annotations correpondent to xml tags
-------------------------------------------

                 Key: JBAOP-456
                 URL: http://jira.jboss.com/jira/browse/JBAOP-456
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 2.0.0.alpha5
            Reporter: Flavia Rainone
            Priority: Optional


There are configurations that can be done only with xml tags.

This task is about adding annotation configuaration equivalent to all xml tags JBoss AOP supports (except for: tags that already have an annotation equivalent; and for configurations that should be done only in 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 lists.jboss.org  Fri Aug 31 15:37:19 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 31 Aug 2007 15:37:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-456) Create annotations
 correpondent to xml tags
In-Reply-To: <10621792.1188589038704.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8448353.1188589039646.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-456?page=comments#action_12374833 ] 
            
Flavia Rainone commented on JBAOP-456:
--------------------------------------

This task also includes the addition of examples to the tutorial.

> Create annotations correpondent to xml tags
> -------------------------------------------
>
>                 Key: JBAOP-456
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-456
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 2.0.0.alpha5
>            Reporter: Flavia Rainone
>            Priority: Optional
>
> There are configurations that can be done only with xml tags.
> This task is about adding annotation configuaration equivalent to all xml tags JBoss AOP supports (except for: tags that already have an annotation equivalent; and for configurations that should be done only in 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 lists.jboss.org  Fri Aug 31 15:39:26 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 31 Aug 2007 15:39:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-457) Create annotations
 for Binding advice stacks
Message-ID: <11910965.1188589166019.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create annotations for Binding advice stacks
--------------------------------------------

                 Key: JBAOP-457
                 URL: http://jira.jboss.com/jira/browse/JBAOP-457
             Project: JBoss AOP
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 2.0.0.alpha5
            Reporter: Flavia Rainone
            Priority: Minor


We should allow a way of binding advice stacks by using 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 lists.jboss.org  Fri Aug 31 15:46:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-641) re-implement the
 callback polling for http transport to reduce latency
In-Reply-To: <4571412.1164899455840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3322395.1188589578458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-641?page=all ]

Ron Sigal closed JBREM-641.
---------------------------

    Resolution: Done

This issue was reopened to add fix version 2.2.2.GA.  It can now be closed again.

> re-implement the callback polling for http transport to reduce latency
> ----------------------------------------------------------------------
>
>                 Key: JBREM-641
>                 URL: http://jira.jboss.com/jira/browse/JBREM-641
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon), 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 15:48:34 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-743) For polling callback
 handler, 
 org.jboss.remoting.Client.addListener() should create only one
 CallbackPoller per InvokerCallbackHandler
In-Reply-To: <28950543.1178341672458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5438893.1188589714008.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-743?page=all ]

Ron Sigal closed JBREM-743.
---------------------------

    Resolution: Done

Unit test is passing on cruisecontrol.

> For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-743
>                 URL: http://jira.jboss.com/jira/browse/JBREM-743
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. 
> The semantics, according to Chapter 5 of the Remoting guide, should be
> If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect.
> So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 15:52:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-747)
 org.jboss.remoting.transport.Connector should unregister server invoker
 from MBeanServer
In-Reply-To: <8850851.1179472312226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26988948.1188589938253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-747?page=all ]

Ron Sigal closed JBREM-747.
---------------------------

    Resolution: Done

The fix has been applied to Remoting 2.2.2.GA (branch remoting_2_2_0_GA).

> org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-747
>                 URL: http://jira.jboss.com/jira/browse/JBREM-747
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one).  
> The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception 
> javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
>         at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799)
> The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered.  The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker.   As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory 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 lists.jboss.org  Fri Aug 31 15:56:19 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:56:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18045902.1188590179716.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-749?page=comments#action_12374841 ] 
            
Ron Sigal commented on JBREM-749:
---------------------------------

Mistake in previous comment:  the unit test is org.jboss.test.remoting.transport.bisocket.SecondaryServerSocketTestCase.

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 15:58:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31112337.1188590298487.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-749?page=all ]

Ron Sigal closed JBREM-749.
---------------------------

    Resolution: Done

The changes have been applied to branch remoting_2_x and the unit test is passing on cruisecontrol.

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:25:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 16:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-754) Reset timeout on each
 use of HttpURLConnection
In-Reply-To: <3212428.1181272151600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22825904.1188591918299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-754?page=all ]

Ron Sigal closed JBREM-754.
---------------------------

    Resolution: Done

Now that the changes have appeared in Remoting 2.2.2.GA, this issue can be closed again.

> Reset timeout on each use of HttpURLConnection
> ----------------------------------------------
>
>                 Key: JBREM-754
>                 URL: http://jira.jboss.com/jira/browse/JBREM-754
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Even though each call to org.jboss.remoting.transport.http.HTTPClientInvoker.invoke() creates a new HttpURLConnection, it seems that the HttpURLConnection implementation caches underlying connections.  When an org.jboss.remoting.ConnectionValidator is running, it connects to the same server as ordinary HTTPClientInvokers used by the application, but it sets a timeout of 1000.  If no timeout value is configured for application connections, then HTTPClientInvoker does not set a timeout on the HttpURLConnection, and a connection with a timeout of 1000 might get reused.
> If no timeout is configured, HTTPClientInvoker should explicitly set the HttpURLConnection connect and read timeouts to 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 lists.jboss.org  Fri Aug 31 16:37:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-755) Make
 ConnectorValidator parameters configurable
In-Reply-To: <9961988.1181953572529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20548126.1188592638570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-755?page=all ]

Ron Sigal closed JBREM-755.
---------------------------

    Resolution: Done

Now that the changes have been applied to Remoting 2.2.2.GA, the issue can be closed again.

> Make ConnectorValidator parameters configurable
> -----------------------------------------------
>
>                 Key: JBREM-755
>                 URL: http://jira.jboss.com/jira/browse/JBREM-755
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Currently org.jboss.remoting.ConnectionValidator hard codes the timeout value (1000 ms) and the number of attempts (1) to get a socket (socket transport family only).  It would be useful to be able to configure these parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:37:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12654837.1188592638769.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12374858 ] 
            
Sohil Shah commented on JBPORTAL-1626:
--------------------------------------

This problem is becuase of weird locking issue that crops up with usage of jboss-cache-1.4.1. 

Thats the version packaged with 4.2.1.GA and the way to fix this is to remove the following jar file:

/server-config/lib/jboss-cache-jdk50.jar.

Compatibility with jboss-cache-1.4.1 will have to be looked into further, maybe even probably with some help from JBoss Cache team.

Digging deeper into the issue, in 1.4.1 jboss cache system seems to be timing out trying to grab a read lock on a cache node due to the presence of a write lock on that node.

However, in this usecase, there is clearly no write access being made to the jboss cache node (programmatically), so I am puzzled as to where the write lock on the node is coming from.

Everything works fine when the NodeLockingScheme is set to OPTMISTIC instead of PESSIMISTIC. But, this is not a solution.

For now, in JBoss-4.2.1, the /server-config/lib/jboss-cache-jdk50.jar needs to be deleted, so that the jboss-cache-1.4.0 packaged with the portal release will be used

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:39:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1626) FIrst access to
 a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31652829.1188592758664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=all ]

Sohil Shah resolved JBPORTAL-1626.
----------------------------------

    Resolution: Done

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:41:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1669) Make the
 JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
Message-ID: <14562486.1188592878261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make the JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
-----------------------------------------------------------------------

                 Key: JBPORTAL-1669
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1669
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal CMS
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
            Priority: Minor
             Fix For: 2.6.3 Final


For details look at http://jira.jboss.com/jira/browse/JBPORTAL-1626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:41:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1669) Make the
 JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
In-Reply-To: <14562486.1188592878261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <695499.1188592878384.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1669?page=all ]

Sohil Shah updated JBPORTAL-1669:
---------------------------------

    Affects Version/s: 2.6.1 Final
                       2.6.2 Final

> Make the JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1669
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1669
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final, 2.6.2 Final
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.6.3 Final
>
>
> For details look at http://jira.jboss.com/jira/browse/JBPORTAL-1626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:43:37 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:43:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1669) Make the
 JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
In-Reply-To: <14562486.1188592878261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31980675.1188593017383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1669?page=comments#action_12374860 ] 
            
Sohil Shah commented on JBPORTAL-1669:
--------------------------------------

JBoss Cache 1.4.1 ships with JBoss-4.2.1, hence this task will help with a better out-of-the-box experience
without requiring the fix mentioned in the refered task

> Make the JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1669
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1669
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final, 2.6.2 Final
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.6.3 Final
>
>
> For details look at http://jira.jboss.com/jira/browse/JBPORTAL-1626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 17:06:13 2007
From: jira-events at lists.jboss.org (Sol Kindle (JIRA))
Date: Fri, 31 Aug 2007 17:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (HIBERNATE-55) No way to
 specify Connection Release Mode in HMBean
In-Reply-To: <3485157.1167733226907.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11850104.1188594373126.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/HIBERNATE-55?page=comments#action_12374868 ] 
            
Sol Kindle commented on HIBERNATE-55:
-------------------------------------

I just upgraded from hibernate 3.0.5 to 3.2.4.sp1 (included with JBoss 4.2.1) and now my application which has been running for two years is getting the "Closing a connection for you.  Please close them yourself" log message and a STACKTRACE.  I am also running hibernate as an MBean. 

1) Is there a workaound for this issue?  
2) Is it OK to just call hsession.close() at the end of the EJB method getting this warning?  Or is this indicative of some other problem.

Thank you.

> No way to specify Connection Release Mode in HMBean
> ---------------------------------------------------
>
>                 Key: HIBERNATE-55
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-55
>             Project: Hibernate
>          Issue Type: Feature Request
>            Reporter: Mohammed Sadiq
>         Assigned To: Steve Ebersole
>
> In my application I have employed an Hibernate MBean for session factory creation and binding it to JNDI and I've added a new overload for the SessionFactory.openSession(Interceptor, ConnectionReleaseMode) method to oveeride the default connection release mode.
>  
> The default connection release mode for any Hibernate session created using the session factory deployed through a Hibernate MBean configuration is taken as "after_statement".
> It will be more helpful, if there exists an MBean attribute "ConnectionReleaseMode" which can thake the enumerated values from the org.hibernate.ConnectionReleaseMode.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 17:15:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 17:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-756) CallbackPoller should
 shut down if too many errors occur.
In-Reply-To: <21704098.1182228191615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27182730.1188594918222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-756?page=all ]

Ron Sigal closed JBREM-756.
---------------------------

    Resolution: Done

Now that the changes have been applied to Remoting 2.2.2.GA, this issue can be closed again.

> CallbackPoller should shut down if too many errors occur.
> ---------------------------------------------------------
>
>                 Key: JBREM-756
>                 URL: http://jira.jboss.com/jira/browse/JBREM-756
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.callback.CallbackPoller will keep running even if the connection is broken or server crashes.  It should be possible to specify a maximum number of errors, after which CallbackPoller will quit polling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 17:35:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1670) Add styling to
 Portal object names outside of tables
Message-ID: <4041277.1188596118220.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add styling to Portal object names outside of tables
----------------------------------------------------

                 Key: JBPORTAL-1670
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1670
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Fri Aug 31 17:35:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1670) Add styling to
 Portal object names outside of tables
In-Reply-To: <4041277.1188596118220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3494907.1188596118307.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1670?page=all ]

Chris Laprun resolved JBPORTAL-1670.
------------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final
       Resolution: Done

> Add styling to Portal object names outside of tables
> ----------------------------------------------------
>
>                 Key: JBPORTAL-1670
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1670
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Fri Aug 31 17:35:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1671) Rework portlet
 definitions page
Message-ID: <17374104.1188596118417.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rework portlet definitions page
-------------------------------

                 Key: JBPORTAL-1671
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1671
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Fri Aug 31 17:37:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1671) Rework portlet
 definitions page
In-Reply-To: <17374104.1188596118417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19852006.1188596238194.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1671?page=all ]

Chris Laprun updated JBPORTAL-1671:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final
             Priority: Minor  (was: Major)

> Rework portlet definitions page
> -------------------------------
>
>                 Key: JBPORTAL-1671
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1671
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Fri Aug 31 17:48:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Fri, 31 Aug 2007 17:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-278) endpoint reference in
 <from> is not validated against the available partner link roles
Message-ID: <12462989.1188596898196.JavaMail.jira@cloud.prod.atl2.jboss.com>

endpoint reference in <from> is not validated against the available partner link roles
--------------------------------------------------------------------------------------

                 Key: BPEL-278
                 URL: http://jira.jboss.com/jira/browse/BPEL-278
             Project: JBoss jBPM BPEL
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Engine
    Affects Versions: jBPM BPEL 1.1 beta 3
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1 GA


Consider the following partner link declaration.

<partnerLink name="ConfiscationTaskMngLink" partnerLinkType="wsdl:ConfiscationTaskMngLink" partnerRole="ConfiscationTaskMngProvider" />

The following from-spec is invalid because the above partner link does not specify myRole:

<from endpointReference="myRole" partnerLink="ConfiscationTaskMngLink" />

This error is not caught during static analysis.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:05:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4974280.1188605118214.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-757?page=comments#action_12374880 ] 
            
Ron Sigal commented on JBREM-757:
---------------------------------

The test method additions did not properly test polled callbacks.

Now, testQuickRemoveListener has been split into testQuickRemovePushListener() and testQuickRemovePullListner, and testQuickRemoveListenerZeroTimeout has been split into testQuickRemovePushListenerZeroTimeout and testQuickRemovePullListenerZeroTimeout.  For transports that are not bidirectional, quick versions of Client.disconnect() and quick Client.removeListener()  will be tested for polled callbacks.

Also, unit tests have been added for the bisocket transport.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:12:33 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:12:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7662425.1188605553692.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-757?page=comments#action_12374881 ] 
            
Ron Sigal commented on JBREM-757:
---------------------------------

Set log level to DEBUG for SocketQuickDisconnectTestCase in response to cruisecontrol failure: http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html.

Don't forget to reset it to INFO before closing issue.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:12:33 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:12:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8828130.1188605553850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-757?page=all ]

Ron Sigal updated JBREM-757:
----------------------------

    Fix Version/s:     (was: 2.2.2.GA)

Removing fix version 2.2.2.GA, which has been release.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:16:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-761) NPE in
 BisocketServerInvoker$ControlConnectionThread
In-Reply-To: <9608977.1183001997620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19649052.1188605778307.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-761?page=all ]

Ron Sigal closed JBREM-761.
---------------------------

    Fix Version/s:     (was: 2.4.0.Beta1 (Pinto))
       Resolution: Done

The fix has been applied to branch remoting_2_x.  Branch remoting_2_2_0_SP4_CP will be eliminated, since Remoting 2.2.2.GA will be used in place of a CP update of 2.2.0.SP4.

> NPE in BisocketServerInvoker$ControlConnectionThread
> ----------------------------------------------------
>
>                 Key: JBREM-761
>                 URL: http://jira.jboss.com/jira/browse/JBREM-761
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.2.2.GA
>
>
> From Tim Fox:
> Here's one I saw today:
> @main 18:11:54,129 INFO  [FailoverTest] tearing down
> Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException
>        at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669)
> It seems pretty harmless, but nevertheless I thought I'd inform 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 lists.jboss.org  Fri Aug 31 20:31:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15338341.1188606678260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-766?page=all ]

Ron Sigal closed JBREM-766.
---------------------------

    Resolution: Done

Changes have been applied to branch remoting_2_x.

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:33:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21426049.1188606798230.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-771?page=all ]

Ron Sigal closed JBREM-771.
---------------------------

    Resolution: Done

The changes have been applied to branch remoting_2_x, and the unit test passes on cruisecontrol.

> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:35:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-774)
 BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should
 close control socket
In-Reply-To: <6131196.1184213431580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28602650.1188606918274.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-774?page=all ]

Ron Sigal closed JBREM-774.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x, and the unit test passes on cruisecontrol.

> BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should close control socket
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBREM-774
>                 URL: http://jira.jboss.com/jira/browse/JBREM-774
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> If cpu overload or network congestion causes a control connection PING to get delayed, the client side org.jboss.remoting.transport.bisocket.Bisocket.BisocketServerInvoker.ControlMonitorTimerTask will tell the server side BisocketServerInvoker.SecondaryServerSocketThread to replace the control socket.  
> If org.jboss.remoting.transport.bisocket.Bisocket.BisocketClientInvoker.replaceControlSocket() does not close the old control socket, and if the client is still alive, the client side BisocketServerInvoker.ControlConnectionThread will be blocked trying to read from an old control connection, which is no longer in use on the server side.
> Also, BisocketClientInvoker.handleDisconnect() should close the control socket.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:37:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27941810.1188607038317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-775?page=all ]

Ron Sigal closed JBREM-775.
---------------------------

    Resolution: Done

Fix has been applied to branch remoting_2_x.

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:39:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-778)
 BisocketServerInvoker.start() creates a new static Timer each time
In-Reply-To: <3736496.1184968967071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12955523.1188607158245.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-778?page=all ]

Ron Sigal closed JBREM-778.
---------------------------

    Resolution: Done

Fix has been applied to branch remoting_2_x, and unit test passes on cruisecontrol.

> BisocketServerInvoker.start() creates a new static Timer each time
> ------------------------------------------------------------------
>
>                 Key: JBREM-778
>                 URL: http://jira.jboss.com/jira/browse/JBREM-778
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start() creates a new static Timer each time.  It should only create a new Timer if (1) there is no existing Timer, or (2) the existing Timer has shut down.  See the similar issue JBREM-748.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:51:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13316879.1188607878230.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-782?page=all ]

Ron Sigal closed JBREM-782.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x.

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:54:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-784) Use separate maps for
 control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13265663.1188608058202.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-784?page=all ]

Ron Sigal closed JBREM-784.
---------------------------

    Resolution: Done

Fix has been applied to branch remoting_2_x, and unit test passes on cruisecontrol.

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:56:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23500502.1188608191403.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-785?page=all ]

Ron Sigal closed JBREM-785.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x, and the unit test passes on cruisecontrol.

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:56:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26481091.1188608191523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-787?page=all ]

Ron Sigal closed JBREM-787.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x.

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:56:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <793843.1188608191634.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-788?page=all ]

Ron Sigal closed JBREM-788.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x.

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:02:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29808709.1188608538265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-790?page=all ]

Ron Sigal closed JBREM-790.
---------------------------

    Resolution: Done

A "running" variable has been added to PingTimerTask in conjunction with JBREM-797, which leads to a slightly different solution on the remoting_2_x branch.

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Fri Aug 31 21:02:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-794)
 LeasePinger.addClient() should not
 create a new LeaseTimerTask if none currently exists
In-Reply-To: <18755133.1187587681051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2059694.1188608538408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-794?page=all ]

Ron Sigal closed JBREM-794.
---------------------------

    Resolution: Done

Unit test passes on cruisecontrol.

> LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists
> ---------------------------------------------------------------------------------------
>
>                 Key: JBREM-794
>                 URL: http://jira.jboss.com/jira/browse/JBREM-794
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> When org.jboss.remoting.LeasePinger.addClient() adds a new org.jboss.remoting.Client with a shorter ping period, it restarts the LeaseTimerTask.  However, org.jboss.remoting.MicroRemoteClientInvoker.establishLease() calls LeasePinger.addClient() before it calls LeasePinger.startPing().  LeasePinger incorrectly creates a LeaseTimerTask in addClient() and then creates a second one in startPing().
> LeasePinger.addClient() should be changed so that it starts a new LeaseTimerTask only if one already 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 lists.jboss.org  Fri Aug 31 21:14:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-798) Implement quick
 Client.removeListener() for polled callbacks, part 2
Message-ID: <26306549.1188609258232.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement quick Client.removeListener() for polled callbacks, part 2
--------------------------------------------------------------------

                 Key: JBREM-798
                 URL: http://jira.jboss.com/jira/browse/JBREM-798
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


This issue is a continuation of JBREM-757.   There are two additions:

1. The unit tests org.jboss.test.remoting.transport.http.timeout.HttpQuickDisconnectTestCase and org.jboss.test.remoting.transport.socket.timeout.SocketQuickDisconnectTestCase did not properly test the the quick version of org.jboss.remoting.Client.removeListener() in the case of polled callbacks.

2. The facility should be tested for the RMI transport when per invocation timeouts are implemented for that transport. (See JBREM-701.)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:18:29 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30135738.1188609509447.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-757?page=all ]

Ron Sigal updated JBREM-757:
----------------------------

    Fix Version/s: 2.2.2.GA
                       (was: 2.4.0.Beta1 (Pinto))

Adding fix version 2.2.2.GA back.  No more changes will be made for 2.2.2.GA.  The remaining concerns associated with this issue will be addressed in Remoting 2.4.0 in conjunction with JBREM-798.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:20:22 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:20:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33009081.1188609622950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-757?page=all ]

Ron Sigal closed JBREM-757.
---------------------------

    Resolution: Done

All further concerns related to this issue will be addressed in Remoting 2.4.0 in conjunction with JBREM-798.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:25:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.2.GA
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21068690.1188609918208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

        Fix Version/s:     (was: 2.4.0.Beta1 (Pinto))
    Affects Version/s: 2.2.2.GA
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4)
                           (was: 2.2.1.GA)

> Release 2.2.2.GA
> ----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 31 21:39:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-731) Address of secondary
 server
 socket should be acquired each time a control connection is created.
In-Reply-To: <2294620.1175908141216.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <418254.1188610758231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-731?page=all ]

Ron Sigal updated JBREM-731:
----------------------------

    Fix Version/s: 2.2.2.GA

Adding fix version 2.2.2.GA, since this issue was, in fact, resolved in 2.2.2.GA.

> Address of secondary server socket should be acquired each time a control connection is created.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-731
>                 URL: http://jira.jboss.com/jira/browse/JBREM-731
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.GA (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Scenario:  Client is connected to a server, server dies, and server is restarted (with same InvokerLocator).  The new server creates a secondary server socket on a different port than the previous server, but the client invoker retains the old secondary server socket InvokerLocator.  When a new Client is created, the old client invoker gets reused, and it isn't possible to create a control connection.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:41:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-731) Address of secondary
 server socket
 should be acquired each time a control connection is created.
In-Reply-To: <2294620.1175908141216.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33239140.1188610878224.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-731?page=all ]

Ron Sigal closed JBREM-731.
---------------------------

    Resolution: Done

Unit tests pass on cruisecontrol.

> Address of secondary server socket should be acquired each time a control connection is created.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-731
>                 URL: http://jira.jboss.com/jira/browse/JBREM-731
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.GA (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Scenario:  Client is connected to a server, server dies, and server is restarted (with same InvokerLocator).  The new server creates a secondary server socket on a different port than the previous server, but the client invoker retains the old secondary server socket InvokerLocator.  When a new Client is created, the old client invoker gets reused, and it isn't possible to create a control connection.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:48:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-799) Add a separate
 timeout parameter for callback clients, part 2
Message-ID: <4676162.1188611298194.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a separate timeout parameter for callback clients, part 2
-------------------------------------------------------------

                 Key: JBREM-799
                 URL: http://jira.jboss.com/jira/browse/JBREM-799
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


This issue is a continuation of JBREM-765 "Add a separate timeout parameter for callback clients".  

The changes have been applied to branches remoting_2_2_0_GA and remoting_2_x, but unit tests exist only for transports socket and bisocket.  A unit test should be written for the RMI transport as well.  However, no additional changes will be made to Remoting 2.2.2.GA, so this issue is introduced for 2.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 lists.jboss.org  Fri Aug 31 21:52:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1645319.1188611538457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-765?page=all ]

Ron Sigal closed JBREM-765.
---------------------------

    Resolution: Done

The provision of a unit test for the RMI transport will be done under JBREM-799 "Add a separate timeout parameter for callback clients, part 2".

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:59:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27042680.1188611958279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-767?page=all ]

Ron Sigal closed JBREM-767.
---------------------------

    Resolution: Done

Fixes for JBREM-765, JBREM-787, and having BisocketClientInvoker.handleDisconnect() wake up any threads waiting in BisocketClientInvoker.createSocket() have been applied to branch remoting_2_x.

The proposed fix "Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client fails." has not been implemented, since it adds a function for which PingTimerTask was not designed.

The unit test is passing on cruisecontrol.

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Fri Aug 31 22:01:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 22:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-796) Verify Remoting 2.2.2
 is compatible with earlier versions
In-Reply-To: <17644775.1187843058201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4442627.1188612078204.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-796?page=all ]

Ron Sigal closed JBREM-796.
---------------------------

    Resolution: Done

Running tests.versioning.all shows that Remoting from branch 2_2_0_GA tagged remoting_2_2_2_GA (i.e., Remoting 2.2.2.GA) is compatible with versions:

   2_2_0_SP4
   2_0_0_GA
   1_4_6_GA
   1_4_4_GA
   1_4_3_GA

> Verify Remoting 2.2.2 is compatible with earlier versions
> ---------------------------------------------------------
>
>                 Key: JBREM-796
>                 URL: http://jira.jboss.com/jira/browse/JBREM-796
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> Need to add version 2.2.0.SP4 jboss-remoting.jar to src/etc/lib and run tests.versioning.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 lists.jboss.org  Fri Aug 31 23:38:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 23:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-800) Adjust timout values
 to avoid cruisecontrol failures
Message-ID: <29811097.1188617898218.JavaMail.jira@cloud.prod.atl2.jboss.com>

Adjust timout values to avoid cruisecontrol failures
----------------------------------------------------

                 Key: JBREM-800
                 URL: http://jira.jboss.com/jira/browse/JBREM-800
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


It seems that some tests fail on cruisecontrol because a busy machine causes timout deadlines to be missed.  For example, 

    http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html

This issue will be an umbrella issue to cover adjusting timeout values.  If a test continues to fail despite updated timeout values, it will need a JIRA issue of its own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 23:45:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 23:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-800) Adjust timout
 values to avoid cruisecontrol failures
In-Reply-To: <29811097.1188617898218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1807917.1188618318249.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-800?page=comments#action_12374911 ] 
            
Ron Sigal commented on JBREM-800:
---------------------------------

The cruisecontrol failure referenced above was org.jboss.test.remoting.transport.socket.timeout.CallbackTimeoutTestCase(java_serialization).

> Adjust timout values to avoid cruisecontrol failures
> ----------------------------------------------------
>
>                 Key: JBREM-800
>                 URL: http://jira.jboss.com/jira/browse/JBREM-800
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> It seems that some tests fail on cruisecontrol because a busy machine causes timout deadlines to be missed.  For example, 
>     http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html
> This issue will be an umbrella issue to cover adjusting timeout values.  If a test continues to fail despite updated timeout values, it will need a JIRA issue of its own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 23:50:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 23:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-800) Adjust timout
 values to avoid cruisecontrol failures
In-Reply-To: <29811097.1188617898218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25089115.1188618618227.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-800?page=comments#action_12374912 ] 
            
Ron Sigal commented on JBREM-800:
---------------------------------

Extended timeout to 2000 in org.jboss.test.remoting.transport.socket.timeout.CallbackTimeoutTestCase.testOnewayCallbackTimeout().

> Adjust timout values to avoid cruisecontrol failures
> ----------------------------------------------------
>
>                 Key: JBREM-800
>                 URL: http://jira.jboss.com/jira/browse/JBREM-800
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> It seems that some tests fail on cruisecontrol because a busy machine causes timout deadlines to be missed.  For example, 
>     http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html
> This issue will be an umbrella issue to cover adjusting timeout values.  If a test continues to fail despite updated timeout values, it will need a JIRA issue of its own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 00:30:49 2007
From: jira-events at lists.jboss.org (Elias Ross (JIRA))
Date: Wed, 1 Aug 2007 00:30:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMICROCONT-198) jboss-kernel
 and
 jboss-aop-mc-int have compile dependencies on jboss-test and junit
In-Reply-To: <24306414.1185428327176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27989407.1185942649354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-198?page=all ]

Elias Ross reopened JBMICROCONT-198:
------------------------------------

             
Those dependencies could be made optional.

http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html 


> jboss-kernel and jboss-aop-mc-int have compile dependencies on jboss-test and junit
> -----------------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-198
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-198
>             Project: JBoss MicroContainer
>          Issue Type: Task
>            Reporter: Elias Ross
>
> jboss-test (and its dependencies) and junit are pulled into projects that depend on "jboss-kernel" and "jboss-aop-mc-int" because the project contains child classes of TestCase within src/main/java ... Probably the best way to deal with this is to create a separate jboss-kernel-test and mc-int-test artifacts.
> These dependencies pull in:
> junit\junit\4.1\junit-4.1.jar
> jboss\profiler\jvmti\jboss-profiler-jvmti\1.0.0.CR5\jboss-profiler-jvmti-1.0.0.CR5.jar
> jboss\jboss-test\1.0.4-SNAPSHOT\jboss-test-1.0.4-SNAPSHOT.jar
> which aren't relevant to people's runtime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 00:40:50 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 1 Aug 2007 00:40:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3986) OutOfMemory
 exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25977153.1185943250769.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3986?page=comments#action_12370647 ] 
            
Anil Saldhana commented on JBAS-3986:
-------------------------------------

Are your users doing a web login? If yes, are they logging out? When they log out, are you invalidating the session? A session invalidation routine does flush the security cache. So if 1 user is logging in, on log out, the entry is removed. If not, the entry exists until the cache times out.

If not, set your cache time outs to a lower value. In a high volume system, system resources are precious (Http Sessions, cache objects). You have to set the time outs to a manageable setting.

> OutOfMemory exception due to TimedCachePolicy in JAAS
> -----------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>            Priority: Critical
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 00:59:58 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 1 Aug 2007 00:59:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4584) Upgrade
 JBossMessaging to 1.4.0.CR1
In-Reply-To: <31379004.1185567589124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19580815.1185944398832.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4584?page=comments#action_12370648 ] 
            
Clebert Suconic commented on JBAS-4584:
---------------------------------------

It was an accident... 

I was investigating this issue... 

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114642

and I didn't mean to commit that duh

If you could just revert those lines please!

> Upgrade JBossMessaging to 1.4.0.CR1
> -----------------------------------
>
>                 Key: JBAS-4584
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4584
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JB5-Messaging
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 01:38:49 2007
From: jira-events at lists.jboss.org (David Sheth (JIRA))
Date: Wed, 1 Aug 2007 01:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1029) calling
 getGroupTaskList results in 4N queries being made to the database
Message-ID: <30255553.1185946729350.JavaMail.jira@cloud.prod.atl2.jboss.com>

calling getGroupTaskList results in 4N queries being made to the database
-------------------------------------------------------------------------

                 Key: JBPM-1029
                 URL: http://jira.jboss.com/jira/browse/JBPM-1029
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: David Sheth
         Assigned To: Tom Baeyens


In the seam 2.0.0.Beta 1 dvdstore example, which uses jbpm-jpdl 3.2.1, one of the admin pages lists all the tasks assigned to the group of the admin, allowing the admin to assign one of the tasks to him or herself. In this page, a task represents an order placed in the store.

Each time a new order is placed in the store, the number of tasks on that admin page goes up by one, as would be expected. However, the number of queries used render the page of tasks goes up by 4 each time a new order is placed.

This seems bad. I asked about this in the seam forum, and got this back from Gavin:

--begin quote
AFAIK, this is a jBPM question, not a Seam question, unless you have evidence otherwise.
--end quote

The specific bit of code in the seam bpm libs that is being called is :

return ManagedJbpmContext.instance()
.getGroupTaskList( new ArrayList( Actor.instance().getGroupActorIds() ) );

which is basically just calling getGroupTaskList on an org.jbpm.JbpmContext instance.


Reference to the post in the seam forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114668 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 03:12:50 2007
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Wed, 1 Aug 2007 03:12:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3986) OutOfMemory
 exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <531126.1185952370172.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3986?page=comments#action_12370651 ] 
            
Ramil Israfilov commented on JBAS-3986:
---------------------------------------

During tests we did correct login and  logout and memory was growing. Problem is that TimedCachePolicy as described in javadoc:  "This is a lazy cache policy in that objects are not checked for expiration until they are accessed."
So it means if user A login and logout it will still remain in cache until next login.
and another problem is that TimedCachePolicy is used by default: inside JaasSecurityManagerService.java there is a DefaultCacheObjectFactory class which instantiate TimedCachePolicy

So for a moment in our production environment  we are using my proposition by extending TimedCachePolicy's run() method.
It is up to you to make your product better !


> OutOfMemory exception due to TimedCachePolicy in JAAS
> -----------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>            Priority: Critical
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 04:15:02 2007
From: jira-events at lists.jboss.org (Wolfgang Betz (JIRA))
Date: Wed, 1 Aug 2007 04:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1049)
 WorkingMemory.iterateFactHandles() generates endless loop with 4.0GA.
In-Reply-To: <27861170.1185871797003.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29570362.1185956102271.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1049?page=all ]

Wolfgang Betz closed JBRULES-1049.
----------------------------------

    Resolution: Cannot Reproduce Bug

Mea culpa, sorry, my fault. It is NOT an issue.
I did not use Iterator.next() as i migrated my project from drools 3. There i used  WorkingMemory.getFactHandles().size(). 
As i used to count facts only for JMX remote monitoring, i did not test the iterator based version for some time.
Anyone having the book "Java for Dummies" at a reasonable price? ;-)



> WorkingMemory.iterateFactHandles() generates endless loop with 4.0GA. 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1049
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1049
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Java 1.6.0_02-b06
>            Reporter: Wolfgang Betz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> WorkingMemory.iterateFactHandles() generates endless loop with 4.0GA for a StatefulSession. I think it worked in earlier 4.0 versions. 
> IterateObjects() does not work 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 lists.jboss.org  Wed Aug  1 04:26:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 1 Aug 2007 04:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1028) BI - UDINESE
In-Reply-To: <21387561.1185904369485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2260282.1185956761892.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1028?page=all ]

Ronald van Kuijk closed JBPM-1028.
----------------------------------

    Resolution: Rejected

> BI - UDINESE
> ------------
>
>                 Key: JBPM-1028
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1028
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Web Interface
>         Environment: dsdsds
>            Reporter: Cristiano Brito
>         Assigned To: Tom Baeyens
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> ddsdsds

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 09:55:49 2007
From: jira-events at lists.jboss.org (Ovidiu Nichifor (JIRA))
Date: Wed, 1 Aug 2007 09:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1619) Multiple
	maximized windows
Message-ID: <8587201.1185976549535.JavaMail.jira@cloud.prod.atl2.jboss.com>

Multiple maximized windows
--------------------------

                 Key: JBPORTAL-1619
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1619
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6 Final
            Reporter: Ovidiu Nichifor
         Assigned To: Julien Viet


Once you authenticate (admin/admin) you'll be brought to the default page of the user account. Suppose the default page contains the "Greetings" and "User" portlets. I have noticed something strange that i don't know if it is really a bug or a feature.

If you follow the next steps:
1. with your browser access: http://<hostname>:<port>/portal/auth/portal/default/default/JSPPortletWindow?windowstate=maximized
2. with your browser access: http://<hostname>:<port>/portal/auth/portal/default/default/UserPortletWindow?windowstate=maximized without normalize first the previous maximized window.

you'll have two windows that are both in the maximized state. Now, the portal should present to you the last maximized window.

If you try to normalize/minimize the maximized window, the portal will display the other maximized window instead of bringing you back to the page in the "normal" state (i.e. with all defined portlets on it).
Is this the way it should work? I've been digging in the JBoss Portal 2.6.ALPHA1 source code and i found a "ensureSingleMaximizedWindow" method in the "org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl" file that does nothing - only throws a FixMe exception. Both JBP-2.6.FINAL & JBP-2.6.ALPHA1 have the same behavior on the test case i described so i assume the maximizing strategy hasn't been 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 lists.jboss.org  Wed Aug  1 10:34:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 10:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8517712.1185978889366.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12370695 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Hi Matthew,

I have worked on this today and I think the feature should be working now. I took the liberty of changing your approach somewhat. 
- I sticked to the changes in your extension point definition
- I changed the interface name to XmlElementMapper, this interface only has the accept(Node) method
- The registry will register all the possible configuration elements for an xml element in a set directly sorted according to the specified priority
- The xml adapter factory will iterate through the sorted set and once it finds a mapper that accepts the dom node create the adapter found in the configuration element
With this approach, I was able to simplify the api (the interface has only one method), to simplify and optimize the implementation of the adapter creation (sorting does only happen once) and to get rid of the default implementation of the mapper.

The only thing I do not know is if this approach works for you, so could you please test it for me? The changes are committed to HEAD

Regards,
Koen

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 10:50:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 10:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-125) problem when creating
 a process project when no jbpm installation is selected
Message-ID: <15859629.1185979849250.JavaMail.jira@cloud.prod.atl2.jboss.com>

problem when creating a process project when no jbpm installation is selected
-----------------------------------------------------------------------------

                 Key: GPD-125
                 URL: http://jira.jboss.com/jira/browse/GPD-125
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Koen Aers
         Assigned To: Koen Aers
             Fix For: jBPM JPDL Designer 3.1.0.CR




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:11:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 11:11:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-125) problem when creating a
 process project when no jbpm installation is selected
In-Reply-To: <15859629.1185979849250.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2424465.1185981109772.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-125?page=all ]

Koen Aers closed GPD-125.
-------------------------

    Resolution: Done

> problem when creating a process project when no jbpm installation is selected
> -----------------------------------------------------------------------------
>
>                 Key: GPD-125
>                 URL: http://jira.jboss.com/jira/browse/GPD-125
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:27:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 11:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28723320.1185982069411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers closed GPD-78.
------------------------

    Resolution: Done

I am closing this as I cannot reproduce the problem. Please feel free to reopen it and attach a process that shows the problem.

Regards,
Koen

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  1 11:29:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 1 Aug 2007 11:29:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1023) Default local
 interface is not picked up if class is woven with JBoss AOP
Message-ID: <27657471.1185982189290.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default local interface is not picked up if class is woven with JBoss AOP
-------------------------------------------------------------------------

                 Key: EJBTHREE-1023
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1023
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, EJB 3.0 RC9 - Patch 1
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD


If weaving the following bean

public interface SessionLocal{
   void method();
}

@Stateful
public bean Session implements Session{
   void method(){}
}

following weaving it implements Session AND org.jboss.aop.Advised, i.e. > 1 interface so the local proxy does not get bound into JNDI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:51:28 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:51:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-989) Create performance
 test suite to test failover
In-Reply-To: <26116759.1172673610805.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10762693.1185983488504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-989?page=all ]

Manik Surtani updated JBCACHE-989:
----------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

> Create performance test suite to test failover
> ----------------------------------------------
>
>                 Key: JBCACHE-989
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-989
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Should be ideally integrated into cruise control builds, and should test a variety of configurations including sync and async replication, BR, 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 lists.jboss.org  Wed Aug  1 11:51:29 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 1 Aug 2007 11:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-12) Same JBPM project shared
 with each person having different JBPM installation program
In-Reply-To: <23767681.1165564238792.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31482575.1185983489226.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-12?page=all ]

Koen Aers closed GPD-12.
------------------------

    Resolution: Done

If the jBPM runtime used to define the project got deleted or is at a different location, there may be compilation errors, but the workbench does not crash as before

> Same JBPM project shared with each person having different JBPM installation program
> ------------------------------------------------------------------------------------
>
>                 Key: GPD-12
>                 URL: http://jira.jboss.com/jira/browse/GPD-12
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>         Environment: Eclipse, MyEclipseIDE, JBPM 3.1.2
>            Reporter: Tom Baeyens
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> To duplicate have two development machines with exactly the same versions of the software except have the Window->Preferences->JBoss jBPM installation locations in different places.
> Have one of the people create a jBPM project, zip up that project and send it to the user of machine 2. Then have machine 2 import that project into Eclipse. 
> Everything blows up. Many of the other non-related projects in the project tree also begin displaying erratic behavior.
> If both users now synchronize to have their IDEs point to the same jBPM path on each of their machines, the project opens up 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 lists.jboss.org  Wed Aug  1 11:52:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:52:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-989) Create
 performance test suite to test failover
In-Reply-To: <26116759.1172673610805.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23970700.1185983569380.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-989?page=comments#action_12370713 ] 
            
Manik Surtani commented on JBCACHE-989:
---------------------------------------

Specifically cluster healing/recovery time needs to be measured.

> Create performance test suite to test failover
> ----------------------------------------------
>
>                 Key: JBCACHE-989
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-989
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Should be ideally integrated into cruise control builds, and should test a variety of configurations including sync and async replication, BR, 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 lists.jboss.org  Wed Aug  1 11:52:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:52:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-989) Create
 performance test suite to test failover
In-Reply-To: <26116759.1172673610805.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11848586.1185983569591.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-989?page=all ]

Manik Surtani reassigned JBCACHE-989:
-------------------------------------

    Assignee: Phillip Thurmond  (was: Manik Surtani)

> Create performance test suite to test failover
> ----------------------------------------------
>
>                 Key: JBCACHE-989
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-989
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Phillip Thurmond
>             Fix For: 2.1.0.GA
>
>
> Should be ideally integrated into cruise control builds, and should test a variety of configurations including sync and async replication, BR, 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 lists.jboss.org  Wed Aug  1 11:54:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-905) Perform code
 coverage analysis and add missing unit tests
In-Reply-To: <10530221.1166036318578.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9167569.1185983689354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-905?page=all ]

Manik Surtani updated JBCACHE-905:
----------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

> Perform code coverage analysis and add missing unit tests
> ---------------------------------------------------------
>
>                 Key: JBCACHE-905
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-905
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Hany Mesha
>             Fix For: 2.1.0.GA
>
>
> Using a code coverage tool like Clover:
> 1) Analyse current test suite on Branch_JBossCache_1_4_0
> 2) Put up results on a wiki page
> 3) Link wiki page to this JIRA task as well as the JBossCache wiki page
> 4) Analyse gaps in the test suite and either document (on the wiki) as being too simple/obvious to test or create a unit test for this.
> Once 2.0.0 reaches CR1, perform the same on HEAD (or Branch_JBossCache_2_0_0 by then...)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 11:56:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 11:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-983) State transfer test
 failures ( to do with concurrent eviction and activation )
In-Reply-To: <1037043.1172078435420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30996257.1185983809509.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-983?page=all ]

Manik Surtani closed JBCACHE-983.
---------------------------------

    Resolution: Done

> State transfer test failures ( to do with concurrent eviction and activation )
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-983
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-983
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:14:49 2007
From: jira-events at lists.jboss.org (Eric Miles (JIRA))
Date: Wed, 1 Aug 2007 12:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
Message-ID: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>

Import collision when static inner classes of 2 different classes have same name
--------------------------------------------------------------------------------

                 Key: JBRULES-1053
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
            Reporter: Eric Miles
         Assigned To: Mark Proctor
         Attachments: drools-import-collision-test.tar.gz

I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:14:49 2007
From: jira-events at lists.jboss.org (Eric Miles (JIRA))
Date: Wed, 1 Aug 2007 12:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9807600.1185984889614.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1053?page=all ]

Eric Miles updated JBRULES-1053:
--------------------------------

    Attachment: drools-import-collision-test.tar.gz

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Mark Proctor
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:19:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1098) Provide a
 distributed locking mechanism as an option
In-Reply-To: <14012403.1181296451566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17546031.1185985189481.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1098?page=all ]

Manik Surtani updated JBCACHE-1098:
-----------------------------------

    Fix Version/s: 3.2.0
                       (was: 3.0.0)

> Provide a distributed locking mechanism as an option
> ----------------------------------------------------
>
>                 Key: JBCACHE-1098
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1098
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 3.2.0
>
>
> Inefficient and not scalable, but people have asked for it for very specific use 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 lists.jboss.org  Wed Aug  1 12:19:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-60) Partitioned Cache
Message-ID: <15401655.1185985189886.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-60?page=all ]

Manik Surtani updated JBCACHE-60:
---------------------------------

    Fix Version/s: 3.2.0
                       (was: 3.0.0)

> Partitioned Cache
> -----------------
>
>                 Key: JBCACHE-60
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-60
>             Project: JBoss Cache
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 3.2.0
>
>   Original Estimate: 10 weeks
>  Remaining Estimate: 10 weeks
>
> - Distributed load across multiple nodes in a cluster
> - No replication/redundancy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:19:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:19:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-70) Make JBossCache an
	XAResource
Message-ID: <12425973.1185985190221.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-70?page=all ]

Manik Surtani updated JBCACHE-70:
---------------------------------

    Fix Version/s: 3.2.0
                       (was: 3.0.0)

> Make JBossCache an XAResource
> -----------------------------
>
>                 Key: JBCACHE-70
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-70
>             Project: JBoss Cache
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 3.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 lists.jboss.org  Wed Aug  1 12:22:03 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-65) Query on JBossCache
Message-ID: <17008771.1185985323548.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-65?page=all ]

Manik Surtani updated JBCACHE-65:
---------------------------------

    Fix Version/s: 4.0.0
                       (was: 3.0.0)
         Assignee: Manik Surtani  (was: Bela Ban)

> Query on JBossCache
> -------------------
>
>                 Key: JBCACHE-65
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-65
>             Project: JBoss Cache
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 4.0.0
>
>
> XPath ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:25:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-86) invalidate() across
 cluster on a per-region basis
Message-ID: <24871656.1185985549785.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-86?page=all ]

Manik Surtani updated JBCACHE-86:
---------------------------------

    Fix Version/s: 3.0.0
                       (was: 2.1.0.GA)

> invalidate() across cluster on a per-region basis
> -------------------------------------------------
>
>                 Key: JBCACHE-86
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-86
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 3.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 lists.jboss.org  Wed Aug  1 12:27:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:27:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-107) Extract locks from
 TreeCache into LockingTable
Message-ID: <13582917.1185985670083.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-107?page=all ]

Manik Surtani closed JBCACHE-107.
---------------------------------

    Resolution: Rejected

Rejecting; this may be superfluous with MVCC/Striped locking designs for 3.0.

> Extract locks from TreeCache into LockingTable
> ----------------------------------------------
>
>                 Key: JBCACHE-107
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-107
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Used by LockInterceptor and CreateIfNotExistsInterceptor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:27:51 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 1 Aug 2007 12:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3986) OutOfMemory
 exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11357424.1185985671157.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3986?page=all ]

Anil Saldhana updated JBAS-3986:
--------------------------------

    Priority: Major  (was: Critical)

> OutOfMemory exception due to TimedCachePolicy in JAAS
> -----------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.2.2.GA
>
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 12:27:51 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 1 Aug 2007 12:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3986) Active Flushing:
 OutOfMemory exception due to TimedCachePolicy in JAAS
In-Reply-To: <6762998.1168857353275.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7244172.1185985671644.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3986?page=all ]

Anil Saldhana updated JBAS-3986:
--------------------------------

          Summary: Active Flushing: OutOfMemory exception due to TimedCachePolicy in JAAS  (was: OutOfMemory exception due to TimedCachePolicy in JAAS)
    Fix Version/s: JBossAS-4.2.2.GA

> Active Flushing: OutOfMemory exception due to TimedCachePolicy in JAAS
> ----------------------------------------------------------------------
>
>                 Key: JBAS-3986
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3986
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
>         Environment: JDK1.5, solarisx86, JBoss-4.0.4.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.2.2.GA
>
>
> We have a big amount of users who perform logon to jboss.
> After 15 000 user logins we have an OutOfMemory exception.
> During profiling we see that JAASSecurityManager$DomainInfo takes almost all memory. 
> We are using       <attribute name="DefaultCacheTimeout">120</attribute> and       <attribute name="DefaultCacheResolution">60</attribute>
> But memory is only growing. So no objects are removed from authentication cache.
> We tried to disable caching but in that case we had from time to time Authentication failure exception then did logon from multiple clients.
> After digging into source code we saw that object never removed from cache !
> Only then user do re-logon it is checked that principa is expired and removed.
> But it means that If user logged on once it will be always (!!) in cache.
> And it leads to OutOfMemory.
> We had to extend a run() method of TimedCachePolicy to do remove expired objects:
> public void run() {
> 		super.run();
> 		synchronized (entryMap) {
> 			Iterator iter = entryMap.entrySet().iterator();
> 			List<Object> removeentries = new ArrayList<Object>();
> 			while (iter.hasNext()) {
> 				Map.Entry entry = (Map.Entry) iter.next();
> 				TimedEntry value = (TimedEntry) entry.getValue();
> 				if (value.isCurrent(now) == false) {
> 					if(log.isDebugEnabled()){
> 						log.debug("destroying object:"+value);
> 					}
> 						
> 					value.destroy();
> 					removeentries.add(entry.getKey());
> 				}
> 			}
> 			for (Object object : removeentries) {
> 				if(log.isDebugEnabled()){
> 					log.debug("removing object from Map:"+object);
> 				}
> 				entryMap.remove(object);
> 			}
> 		}
> 	}
> Is not it will be much better to do it on original TimedCachePolicy 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 lists.jboss.org  Wed Aug  1 12:27:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:27:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-401) AOP Collection
 CacheSetImpl.add needs to be atomic
Message-ID: <4655244.1185985672051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-401?page=all ]

Manik Surtani reassigned JBCACHE-401:
-------------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> AOP Collection CacheSetImpl.add needs to be atomic
> --------------------------------------------------
>
>                 Key: JBCACHE-401
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-401
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: PojoCache
>            Reporter: Scott Marlow
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>
> CachedSetImpl.add() is not atomic (another thread could be adding the same value at the same time and both threads get past the existence test).
> Current code looks like this:
>    public boolean add(Object o)
>    {
>       if(keySet().contains(o)) // existance test is done under separate lock
>          return false;
>       try {                               // putObject is done under separate lock
>          cache_.putObject(new Fqn(getFqn(), o),o);
>          return true;
>       } catch (CacheException e) {
>          throw new NestedRuntimeException(e);
>       }
>    }
> I think we need to do something like this:
>    public boolean add(Object o)
>    {
>       try {
>          cache_.putIfAbsent(new Fqn(getFqn(), o),o);
>          return true;
>       } catch (CacheException e) {
>          throw new NestedRuntimeException(e);
>       }
>    }
> Will need new api 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 lists.jboss.org  Wed Aug  1 12:29:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:29:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-788) Optimistic locking
 should not REQUIRE transactions!
In-Reply-To: <27121247.1159281521408.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14624844.1185985789276.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-788?page=all ]

Manik Surtani closed JBCACHE-788.
---------------------------------

    Resolution: Rejected

Superfluous in the light of upcoming MVCC changes - JBCACHE-1151

> 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.GA, 1.3.0.GA, 2.0.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 12:31:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-968) Test on 80 node
	cluster
In-Reply-To: <18585896.1170782600399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24464580.1185985909523.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-968?page=comments#action_12370725 ] 
            
Manik Surtani commented on JBCACHE-968:
---------------------------------------

Once we get a hold of a cluster big enough

> Test on 80 node cluster
> -----------------------
>
>                 Key: JBCACHE-968
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-968
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:31:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-968) Test on 80 node
	cluster
In-Reply-To: <18585896.1170782600399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9532174.1185985909666.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-968?page=all ]

Manik Surtani updated JBCACHE-968:
----------------------------------

    Assignee: Phillip Thurmond  (was: Manik Surtani)

> Test on 80 node cluster
> -----------------------
>
>                 Key: JBCACHE-968
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-968
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Phillip Thurmond
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:33:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-617) Pluggable
 optimistic conflict resolution
Message-ID: <503367.1185986029301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-617?page=all ]

Manik Surtani closed JBCACHE-617.
---------------------------------

    Resolution: Rejected

Will be superfluous with MVCC - JBCACHE-1151

> Pluggable optimistic conflict resolution
> ----------------------------------------
>
>                 Key: JBCACHE-617
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-617
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP2
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.1.0.GA
>
>
> Request for child node merge when conflict on Optimistic locking.
> Conflicts include: children addition, removal and modification.
> This would require JBossCache to abstract the conflict resolution and
> enable customers to plugin their own rules on how to solve the conflicts.
> This would be exposed as an API that customers could implement
> according to their business rules.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 12:35:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 12:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-461) Potential bug in
 ReentrantWriterPreferenceReadWriteLock from util.concurrent
Message-ID: <26432240.1185986149301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-461?page=all ]

Manik Surtani closed JBCACHE-461.
---------------------------------

    Resolution: Rejected

May be superfluous with MVCC - JBCACHE-1151 - as this won't rely on lock upgrading at all.

> Potential bug in ReentrantWriterPreferenceReadWriteLock from util.concurrent
> ----------------------------------------------------------------------------
>
>                 Key: JBCACHE-461
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-461
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4, 1.2.4SP1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.1.0.GA
>
>
> Need to discuss on util.concurrent mail list.
> See org.jboss.cache.lock.ReentrantWriterPreference2Readers1WriterLockTest

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 13:09:49 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 1 Aug 2007 13:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7467677.1185988189542.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1053?page=all ]

Edson Tirelli reassigned JBRULES-1053:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Edson Tirelli
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-224) Expose eviction
 management attributes
Message-ID: <24090332.1185992990725.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-224?page=all ]

Manik Surtani updated JBCACHE-224:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Expose eviction management attributes
> -------------------------------------
>
>                 Key: JBCACHE-224
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-224
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We will need to expose the eviction side of management attributes. This is useful for troubleshooting. But keep in mind that it can also depends on the evction policy used as well. Basic ones are:
> 1. How long does the eviction thread take to process the eviction each time? Or the aevergage time?
> 2. What is the current capacity for the event queue?
> 3. How many nodes have been evicted for this wakeup interval and what's the average time it takes?
> 4. How many eviction miss? I.e., try to evict but the node is gone?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-161) Support chain of
	CacheLoaders
Message-ID: <16649251.1185992990563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-161?page=all ]

Manik Surtani updated JBCACHE-161:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Support chain of CacheLoaders
> -----------------------------
>
>                 Key: JBCACHE-161
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-161
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>
> E.g. TcpDelegatingCacheLoader --> JDBCCacheLoader
> First try to find te element from a remote TCP-based Cache. If not found, go to the DB. Wrt storing, we could pick *any* or *all* CacheLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-434) InternalDelegate
 doesn't relocate AOP nodes properly
Message-ID: <5643323.1185992991584.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-434?page=all ]

Manik Surtani updated JBCACHE-434:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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
>         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 lists.jboss.org  Wed Aug  1 14:29:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1004) Genericize POJO
	API
In-Reply-To: <9353345.1173709786762.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28465930.1185992991731.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1004?page=all ]

Manik Surtani updated JBCACHE-1004:
-----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Genericize POJO API
> -------------------
>
>                 Key: JBCACHE-1004
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1004
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Jason T. Greene
>         Assigned To: Jason T. Greene
>
> Use generics where possible and logical

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-3) Expose JGroups
 (protocols, channel) via JMX, provide common JGroups MBean
Message-ID: <26096369.1185992991908.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-3?page=all ]

Manik Surtani updated JBCACHE-3:
--------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Expose JGroups (protocols, channel) via JMX, provide common JGroups MBean
> -------------------------------------------------------------------------
>
>                 Key: JBCACHE-3
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-3
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-30) Multiple MBean
 Configuration Error
Message-ID: <10710160.1185992992128.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-30?page=all ]

Manik Surtani updated JBCACHE-30:
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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
>
> 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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-4) Notification of
 remote modification
Message-ID: <8092708.1185992992261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-4?page=all ]

Manik Surtani updated JBCACHE-4:
--------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Notification of remote modification
> -----------------------------------
>
>                 Key: JBCACHE-4
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-4
>             Project: JBoss Cache
>          Issue Type: Task
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> TreeCache need to emit a node event that is modify by remote
>   only, i.e., local modification won't trigger this event.
>   This event is needed to listen for remote modification when
>   there is a local copy of this instance around so we know that
>   it is dirty. Use cases are: http session repl and TreeCacheAop
>   where after getObject will need a way to know if the underlying
>   fields have been modified remotely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-268) PojoCache
 InternalDelegate can return incorrect AOPInstance object
Message-ID: <12682679.1185992992484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-268?page=all ]

Manik Surtani updated JBCACHE-268:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> PojoCache InternalDelegate can return incorrect AOPInstance object
> ------------------------------------------------------------------
>
>                 Key: JBCACHE-268
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-268
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: PojoCache
>            Reporter: twundke
>         Assigned To: Ben Wang
>
> The getAopInstance(Fqn) method of InternalDelegate currently uses a cache.peek() call to find the AOPInstance object for an FQN. However, I've come across a situation where multiple calls to this method for the same FQN will return different AOPInstance objects.
> To be honest, I'm not sure of the exact situation in which this occurs as I haven't delved deep enough. However, the basic idea is that I have an object graph in the cache, all hanging off one particular root-level object. I then do a fairly major addition/update to a number of children, but don't specifically update the root-level object. After this update I find that InternalDelegate returns a new instance of the AOPInstance class for the root object's FQN, which has now lost its POJO reference etc. This in turn forces a re-creation of the root-level object, which loses a number of transient references that I have set.
> Note that my object graph has a number of circular references back to this root-level object, so I suspect that the AOP machinery is for some reason updating this object during the update of the children, thereby losing the original AOPInstance reference.
> I've put in a quick fix locally that caches references to AOPInstance objects in a HashMap, which follows the idea suggested in the comment for the method. This solves the 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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-413) Split up build.xml
Message-ID: <830639.1185992992672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-413?page=all ]

Manik Surtani updated JBCACHE-413:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Split up build.xml
> ------------------
>
>                 Key: JBCACHE-413
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-413
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> buidl.xml is getting too big. Maybe we should split them up, e.g., split the pojo cache portion is a starter. We can do it as JbossAs with import directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-450) Create a pure
 pojo-based eviction policy
Message-ID: <19443645.1185992992820.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-450?page=all ]

Manik Surtani updated JBCACHE-450:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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
>   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 lists.jboss.org  Wed Aug  1 14:29:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-706) Integrate JMX
 bindings of JBoss Cache and PojoCache with AS5 and MC
In-Reply-To: <11682451.1153375211296.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2313201.1185992992926.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-706?page=all ]

Manik Surtani updated JBCACHE-706:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Integrate JMX bindings of JBoss Cache and PojoCache with AS5 and MC
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-706
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-706
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>
> This will involve:
> 1.  Adding new JMX MBean interface (is this necessary for the MC?  What about standalone use?)
> 2.  Providing sample XML files
> 3.  Updating documentation

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-204) Externalize
 RegionManager.Capacity parameter
Message-ID: <15870252.1185992993222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-204?page=all ]

Manik Surtani updated JBCACHE-204:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Externalize RegionManager.Capacity parameter
> --------------------------------------------
>
>                 Key: JBCACHE-204
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-204
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> RegionManager.CAPACITY is used to determine the size of the eviction event queue. It is fixed now. We should externalize it later such that we can tune the eviction policy performance. E.g., when the load is heavy, we may need to increase the queue size such that it is not blocking.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1061) BeanShell version
 JBossCache uses does not support entering generic Collections
In-Reply-To: <30779018.1179315412371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1508873.1185992993392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1061?page=all ]

Manik Surtani updated JBCACHE-1061:
-----------------------------------

    Fix Version/s:     (was: 2.0.0.CR2)

> BeanShell version JBossCache uses does not support entering generic Collections
> -------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1061
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1061
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.CR1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> Need to investigate whether there's a more up to date version:
> bsh % lang = new ArrayList<String>();
> // Error: Parser Error: Parse error at line 1, column 121.  Encountered: <

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-479) Cache loader to
 load children as well when loading a node
Message-ID: <8763705.1185992993555.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-479?page=all ]

Manik Surtani updated JBCACHE-479:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Cache loader to load children as well when loading a node
> ---------------------------------------------------------
>
>                 Key: JBCACHE-479
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-479
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: Manik Surtani
>         Assigned To: Ben Wang
>
> Requested by Ben, for failing unit test o.j.c.aop.loader.FileCacheLoaderAopCollectionsTest

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-681) PojoCache to
 handle jdom documentation
Message-ID: <30513551.1185992993787.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-681?page=all ]

Manik Surtani updated JBCACHE-681:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> PojoCache to handle jdom documentation
> --------------------------------------
>
>                 Key: JBCACHE-681
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-681
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>
> Idea is to replicate the jdom tree easily with PojoCache. The fine-grained replication can be more efficient. Also object relationship like cycles and inheritance can be handled automatically as well.
> We will need to come up a more concrete 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 lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-933) PojoCache to
 create a cache wrapper to retry when upgradeexception is encountered
In-Reply-To: <10583316.1168431468423.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21091817.1185992994147.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-933?page=all ]

Manik Surtani updated JBCACHE-933:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.CR1)

> PojoCache to create a cache wrapper to retry when upgradeexception is encountered
> ---------------------------------------------------------------------------------
>
>                 Key: JBCACHE-933
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-933
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>
> Current 2.0 release becuase of lock contention on __JBossInternal__, it becomes much more common to have lock UpgradeException. Solutions are:
> 1. Fix the underlying cache lock algorithm to allow lock upgrade. This can be tricky since it affects lots of other codes.
> 2. Re-try the logic in a Cache wrapper when UpgradeException is encountered.
> I think option #2 is the best route 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 lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-990) PojoCache leaks
	memory
In-Reply-To: <12480846.1172775308924.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26879502.1185992994306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-990?page=all ]

Manik Surtani updated JBCACHE-990:
----------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)

> PojoCache leaks memory
> ----------------------
>
>                 Key: JBCACHE-990
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-990
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.ALPHA2, 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>            Priority: Critical
>
> I've included the test from the forum thread into
> tests/perf/org/jboss/cache/manualtests/PojoCacheMemoryLeakTest.java - note that since this is in the "manualtests" package, it will not be run by cruise control.   
> When running from within my IDE, after about 8 loops it bombs with an OOME.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-561) Create a separate
 META-INF sub-directory for PojoCache
Message-ID: <9514621.1185992994565.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-561?page=all ]

Manik Surtani updated JBCACHE-561:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Create a separate META-INF sub-directory for PojoCache
> ------------------------------------------------------
>
>                 Key: JBCACHE-561
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-561
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Separate the PojoCache configuration from regular TreeCache so that user don't get confused.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-237) When remove a Pojo
 with shared
 Collection instances from cache, will need to restore the original
 reference
Message-ID: <11533311.1185992994717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-237?page=all ]

Manik Surtani updated JBCACHE-237:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> When remove a Pojo with shared Collection instances from cache, will need to restore the original reference
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-237
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-237
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2.3
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Currently when Pojos that share Collection instances (e.g., a List sub-object), during putObject operation, it will be replaced by a corresponding proxy at runtime. But when removeObject is called, we will need to restore the original reference instead of still using the dynamic proxy one. That is we need to ditch the dynamic proxy 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 lists.jboss.org  Wed Aug  1 14:29:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-774) PojoCache to use a
 RPC layer to transmit POJO events
In-Reply-To: <22632405.1158560091387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30989244.1185992994950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-774?page=all ]

Manik Surtani updated JBCACHE-774:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> 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: Jason T. Greene
>            Priority: Critical
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> 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 lists.jboss.org  Wed Aug  1 14:29:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:29:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-830) Incorrect
 serialization of Collection and Map proxies
In-Reply-To: <7833208.1162480452576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30112196.1185992995264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-830?page=all ]

Manik Surtani updated JBCACHE-830:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)

> Incorrect serialization of Collection and Map proxies
> -----------------------------------------------------
>
>                 Key: JBCACHE-830
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-830
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.3.0.GA, 1.4.0.GA, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Ben Wang
>
> The PojoCache Collection and Map proxies implement Serializable but don't do anything to override default serialization.  They have non-transient fields with refs to things like the cache itself, so serializing one of these is a big problem -- you serialize the whole cache.
> Not sure what the best solution to this is. Perhaps use writeReplace()?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-5) AOP HTTP session
 replication under Tomcat 5
Message-ID: <9263794.1185993291684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-5?page=all ]

Manik Surtani reopened JBCACHE-5:
---------------------------------

      Assignee:     (was: Ben Wang)
             

> AOP HTTP session replication under Tomcat 5
> -------------------------------------------
>
>                 Key: JBCACHE-5
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-5
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 10 weeks
>  Remaining Estimate: 10 weeks
>
> - JBossCache with aop/aopc
>   - Implemented any required features to 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 lists.jboss.org  Wed Aug  1 14:34:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-35) Externalize the
 buffer queue size in LRUAlgorithm
Message-ID: <4277759.1185993291909.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-35?page=all ]

Manik Surtani reopened JBCACHE-35:
----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Externalize the buffer queue size in LRUAlgorithm
> -------------------------------------------------
>
>                 Key: JBCACHE-35
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-35
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Currently, the LRUAlgorithm use a hard size of 5000 on the buffer queue to process node eviction. We should make this configurable so it can adapt to different enviornment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-115) beforeEviction()
	callback
Message-ID: <167659.1185993292071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-115?page=all ]

Manik Surtani reopened JBCACHE-115:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> beforeEviction() callback
> -------------------------
>
>                 Key: JBCACHE-115
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-115
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.1
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-129) Ensure graceful
 handling of marshalling between different versions
Message-ID: <4850730.1185993292217.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-129?page=all ]

Manik Surtani reopened JBCACHE-129:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Ensure graceful handling of marshalling between different versions
> ------------------------------------------------------------------
>
>                 Key: JBCACHE-129
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-129
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>
> backwards compatibility

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-131) Cache Loaders
 (when unshared, 
 and not used with eviction) Should Persist Transient State Upon Startup
Message-ID: <13893507.1185993292601.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-131?page=all ]

Manik Surtani reopened JBCACHE-131:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-131
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-131
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Jimmy Wilson
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>         Attachments: TreeCache.zip
>
>
> Given the following single, unshared cache loader use case in the TreeCache documentation:
> "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store"
> A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability.
> I have modified TreeCache to handle this situation, and I will attach the modified code to 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 lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-139) Node notification
 event that ecludes myself
Message-ID: <17849714.1185993292785.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-139?page=all ]

Manik Surtani reopened JBCACHE-139:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Node notification event that ecludes myself
> -------------------------------------------
>
>                 Key: JBCACHE-139
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-139
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> It will be nice to have a notification mechanism that can exclude myself (who modifies the node in the first place). This is needed in cache invlidation, 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 lists.jboss.org  Wed Aug  1 14:34:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-154) Ability to
 request cache statisics
Message-ID: <5288029.1185993292983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-154?page=all ]

Manik Surtani reopened JBCACHE-154:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Ability to request cache statisics
> ----------------------------------
>
>                 Key: JBCACHE-154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Rich Dredge
>             Fix For: 2.0.0.GA
>
>
> It would be very helpful to retrieve stats about certain regions of the cache such as:
> - Hit/Miss ratio per region
> - Access counts
> - Number of nodes within a region

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-163) Consolidate jboss
 related libraries
Message-ID: <11789149.1185993293152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ]

Manik Surtani reopened JBCACHE-163:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> 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
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>   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 lists.jboss.org  Wed Aug  1 14:34:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-250) Hierarchical
 caches not working when using JBoss service
Message-ID: <29266301.1185993293831.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-250?page=all ]

Manik Surtani reopened JBCACHE-250:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Hierarchical caches not working when using JBoss service
> --------------------------------------------------------
>
>                 Key: JBCACHE-250
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-250
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3
>            Reporter: Nimrod Rivier
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
>  
> I tried to configure a hierarchical cache, composed of a first-level memory-only cache, 
> and a second-level file-only cache. It seems not to work when I the caches are jboss services, 
> but works when I use plain classes. 
> Details: 
> The caches are created as follows: 
> TreeCacheMBean sCacheSecondLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName1, server); 
> TreeCacheMBean sCacheFirstLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName2, server); 
> LocalDelegatingCacheLoader sCacheLoader = new LocalDelegatingCacheLoader(sCacheSecondLevel.getInstance()); 
> sCacheFirstLevel.setCacheLoader(sCacheLoader); 
> I then insert elements into sCacheFirstLevel, and it seems they are not delegated into sCacheSecondLevel . 
> Adding the following did not help
> sCacheFirstLevel.stopService();
> sCacheFirstLevel.startService();
> sCacheSecondLevel.stopService();
> sCacheSecondLevel.startService();
> When I use the following code to create the caches, everything seems to work fine: 
> sCacheSecondLevel = new TreeCache(); 
> sCacheSecondLevel.setCacheLoaderClass"org.jboss.cache.loader.FileCacheLoader"); 
> Properties filecacheLoaderProperties = new Properties(); 
> filecacheLoaderProperties.put("location","c:\\temp\\cache\\requests"); 
> sCacheSecondLevel.setCacheLoaderConfig(filecacheLoaderProperties); 
> sCacheFirstLevel = new TreeCache(); 
> CacheLoader cacheLoader = new LocalDelegatingCacheLoader (sCacheSecondLevel); 
> sCacheFirstLevel.setCacheLoader(cacheLoader); 
> /* Configure the caches (removed) */ 
> sCacheSecondLevel.createService(); 
> sCacheSecondLevel.startService(); 
> sCacheFirstLevel.createService(); 
> sCacheFirstLevel.startService(); 
>  
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-270) Create a
 notification interceptor
Message-ID: <4864511.1185993294045.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-270?page=all ]

Manik Surtani reopened JBCACHE-270:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Create a notification interceptor
> ---------------------------------
>
>                 Key: JBCACHE-270
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-270
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4beta
>            Reporter: Hany Mesha
>             Fix For: 2.0.0.GA
>
>
> The need has arised to create a notification interceptor to handle the callbacks results from different method call events and interceptors emitted events.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-328) Move attributes
 and getters/setters to interceptors
Message-ID: <28914460.1185993294233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ]

Manik Surtani reopened JBCACHE-328:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> 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
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-332) Webdav interface
 for accessing JBossCache
Message-ID: <5667562.1185993294371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-332?page=all ]

Manik Surtani reopened JBCACHE-332:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Webdav interface for accessing JBossCache
> -----------------------------------------
>
>                 Key: JBCACHE-332
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-332
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>
> Provide a webdav interface for JBossCache. This will enable access, e.g. from Windows Explorer. Any file dragged into a folder will be replicated 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 lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-347) Replay tx if tx
 is created implicitly and fails on commit
Message-ID: <6556542.1185993294458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-347?page=all ]

Manik Surtani reopened JBCACHE-347:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Replay tx if tx is created implicitly and fails on commit
> ---------------------------------------------------------
>
>                 Key: JBCACHE-347
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-347
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> With optimistic locking, we first check for an existing transaction, and if there isn't one, we implicitly start one. Before the method returns, if we started the tx ourselves, we make sure we commit it. 
> There is scope to 'replay' the tx a fixed number of times here if the commit fails.
> At the moment, if the developer explicitly starts a tx before any cache operations, the cache may throw a RollbackException if it is unable to commit. If the developer doesn't explicitly start a tx, the cache may fail silently if it is unable to commit, logging errors but not throwing any exceptions. So there is scope here for silent retries without changing usage semantics.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-431) Remove jboss-XXX
 JARs which contain Nested(Runtime)Exceptions
Message-ID: <23793641.1185993294676.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-431?page=all ]

Manik Surtani reopened JBCACHE-431:
-----------------------------------

      Assignee:     (was: Bela Ban)
             

> Remove jboss-XXX JARs which contain Nested(Runtime)Exceptions
> -------------------------------------------------------------
>
>                 Key: JBCACHE-431
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-431
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-432)
 PropertyConfigurator:
 investigate how to implement parsing functionality without use of
 PropertyEditor
Message-ID: <22266108.1185993294835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-432?page=all ]

Manik Surtani reopened JBCACHE-432:
-----------------------------------

      Assignee:     (was: Ben Wang)
             

> PropertyConfigurator: investigate how to implement parsing functionality without use of PropertyEditor
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-432
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-432
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>             Fix For: 2.0.0.GA
>
>
> Can you look into whether this is feasible ? If not, can you move this issue to 1.4 ?
> If we could get rid of that class, we could remove jboss-common.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 lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-469) JGroups Channel
 reference to be obtained from a factory
Message-ID: <7378848.1185993295108.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-469?page=all ]

Manik Surtani reopened JBCACHE-469:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> JGroups Channel reference to be obtained from a factory
> -------------------------------------------------------
>
>                 Key: JBCACHE-469
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-469
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> The JChannelFactory (will be available in JGroups 2.3 - see JGRP-112) should be used to get a channel instance.
> The JChannelFactory could be obtained by:
> 1) MBeanServer lookup (look up a JChannelFactoryMBean instance)
> JBossCache config will need:
> + JChannelFactoryMBean name
> + JGroups configured stack name
> JBossCache config will not need:
> - Cluster name
> - JGroups settings
> 2) JChannelFactory instantiation
> JBossCache config will need:
> + Cluster name
> + JGroups settings
> JBossCache config will not need:
> - JChannelFactoryMBean name
> - JGroups configured stack 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 lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-478) Translate docs
	into Italian
Message-ID: <24891230.1185993295213.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-478?page=all ]

Manik Surtani reopened JBCACHE-478:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Translate docs into Italian
> ---------------------------
>
>                 Key: JBCACHE-478
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-478
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: Manik Surtani
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> Translating JBoss Cache documentation to Italian.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-508) JBossCache
 bechmark and performance tuning
Message-ID: <4955285.1185993295336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-508?page=all ]

Manik Surtani reopened JBCACHE-508:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> JBossCache bechmark and performance tuning
> ------------------------------------------
>
>                 Key: JBCACHE-508
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-508
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> I have created this task specifically to document our effort in the bechmark and performance tuning process. I am using this tool that I developed to do perf test:http://jira.jboss.com/jira/browse/JBCACHE-503
> Note this load test only emulates the http session pattern now.
> I will document the numbers here that I have found and discussed with Bela.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-543) Consider
 synchronized(this) instead of a separate lock
Message-ID: <14431044.1185993295642.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-543?page=all ]

Manik Surtani reopened JBCACHE-543:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Consider synchronized(this) instead of a separate lock
> ------------------------------------------------------
>
>                 Key: JBCACHE-543
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-543
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>             Fix For: 2.0.0.GA, 2.0.0.ALPHA2
>
>
> This will save one object per node, not a big deal but something.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-544) Remove
	AbstractNode superclass
Message-ID: <21154356.1185993295765.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-544?page=all ]

Manik Surtani reopened JBCACHE-544:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Remove AbstractNode superclass
> ------------------------------
>
>                 Key: JBCACHE-544
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-544
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>             Fix For: 2.0.0.GA
>
>
> If AbstractNode is not used anywhere, it's basically more code to maintain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-519) Investigate why
 tx has a higher thruput than non-tx under perf test
Message-ID: <14777725.1185993295492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-519?page=all ]

Manik Surtani reopened JBCACHE-519:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Investigate why tx has  a higher thruput than non-tx under perf test
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-519
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-519
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> During the perf test, I have discovered that the throughput with tx is higher than the non-tx one. This is very puzzling. I have asked Scot Marlow to double check it for me. The same. 
> Machines are: dev09 and dev17.
> Here are some breakdown numbers:
> 1. Single thread, 3000 loops, 10 ms sleep interval.
> (a) no tx
> -----
> Total time spent (ms) per thread: 202921 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? false
> is: 14 requests/sec
> (b) tx
> ----
> Total time spent (ms) per thread: 200718 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? true
> is: 14 requests/sec
> 2. 100 threads, 0ms sleep interval
> (a) no tx
> -----
> Total time spent (ms) per thread: 49352 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? false
> is: 404 requests/sec
> -----
> Total time spent (ms) per thread: 61240 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 325 requests/sec
> -------- dev04
> Total time spent (ms) per thread: 78871 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 250 requests/sec
> (b) tx
> -----
> Total time spent (ms) per thread: 68770 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? true
> is: 288 requests/sec
> ----
> Total time spent (ms) per thread: 74575 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 263 requests/sec
> --- dev04
> Total time spent (ms) per thread: 80648 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 242 requests/sec

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-546) Move lock related
 operations to a separate utility, such as NodeLock
Message-ID: <12394863.1185993295914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-546?page=all ]

Manik Surtani reopened JBCACHE-546:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Move lock related operations to a separate utility, such as NodeLock
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-546
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-546
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>             Fix For: 2.0.0.GA, 2.0.0.ALPHA2
>
>
> This is to reduce the amount of methods in Node to keep them fairly succinct.
> The lock in a Node itself could be package-protected so that interactions must happen through 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-553) JBossCache
	throughput II
Message-ID: <1407018.1185993296051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-553?page=all ]

Manik Surtani reopened JBCACHE-553:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> JBossCache throughput II
> ------------------------
>
>                 Key: JBCACHE-553
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-553
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Here are the results using the perf test to run our Atl clustering lab. The machines are: 2X 3.0GHZ Xeon, 4GB Ram, GBSwtich, dedicated, 140GB drive.
> The load condition are:
> 400 clients (total), no sleep, 7kbyte payload
> async:
> Cluster size, throughtput (req/sec)
> 8,                  1270 (8.9MB/sec)
> 4,                  1270
> 2,                  1400
> sync:
> Cluster size, throughtput (req/sec)
> 8,                  432 (3.0MB/sec)
> 4,                  480
> 2,                  700

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-562) Disable cache
 loader when no cacheloader class is specified
Message-ID: <21042526.1185993296213.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-562?page=all ]

Manik Surtani reopened JBCACHE-562:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Disable cache loader when no cacheloader class is specified
> -----------------------------------------------------------
>
>                 Key: JBCACHE-562
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-562
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> In 1.3, we support a new form of cacheloader config. However, it is incovenient to disable the cache loader (previously all we need is to specify cacheloaderclass to empty). We should also support this kind of semantics so we can disable it easily. I propose when do createcacheloader, we also check whether the class name is there or not to decide whether to go ahead. If not, we simply log an info 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-696) Look into
 JDBMCacheLoader
 details and potentially promote as a 'recommended' cache loader?
In-Reply-To: <5384804.1152867851629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17499401.1185993296317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-696?page=all ]

Manik Surtani reopened JBCACHE-696:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader?
> ------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-696
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-696
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.3.0.GA
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-708) EOF exception in
 TcpCacheLoader
In-Reply-To: <3434652.1153423391520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16730436.1185993296482.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-708?page=all ]

Manik Surtani reopened JBCACHE-708:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> EOF exception in TcpCacheLoader
> -------------------------------
>
>                 Key: JBCACHE-708
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-708
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> Happens when a node in the cluster dies.  See last few postings in 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-710) FileCacheLoader
 passivation/activation produces recursive exception when loader.remove
 fails
In-Reply-To: <18265876.1153707611477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30540682.1185993296679.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-710?page=all ]

Manik Surtani reopened JBCACHE-710:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
> --------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-710
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-710
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
> In ActivationInterceptor.java, we have:
>             if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
>                if (n.hasChildren()) {
>                   if (allInitialized(n)) {
>                      log.debug("children all initialized");
>                      remove(fqn);
>                   }
>                } else if (loaderNoChildren(fqn)) {
>                   log.debug("no children " + n);
>                   remove(fqn);
>                }
>             }
>          }
>       }
>       return retval;
>    }
>    private void remove(Fqn fqn) throws Exception {
>       loader.remove(fqn);
>       cache.notifyNodeActivate(fqn, false);
>       if (cache.getUseInterceptorMbeans()&& statsEnabled)
>          m_activations++;
>    }
> problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g.,
> cache.get(fqn, key)
> to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion.
> A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid 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 lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-723) Proper collection
	rollback
In-Reply-To: <9144391.1154091011340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32639121.1185993296830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-723?page=all ]

Manik Surtani reopened JBCACHE-723:
-----------------------------------

      Assignee:     (was: Ben Wang)
             

> Proper collection rollback
> --------------------------
>
>                 Key: JBCACHE-723
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-723
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> It is not properly yet via the undointerceptor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8456951.1185993296953.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani reopened JBCACHE-739:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>             Fix For: 2.0.0.GA, 1.4.1.GA
>
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-740) Optimistic
 Locking Scheme: Occasional IllegalStateExceptions on commit
In-Reply-To: <30375980.1155931121396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20937360.1185993297155.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-740?page=all ]

Manik Surtani reopened JBCACHE-740:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Optimistic Locking Scheme: Occasional IllegalStateExceptions on commit
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-740
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-740
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.GA
>         Environment: Linux 2.6.15-26-686 #1 SMP PREEMPT Thu Aug 3 03:13:28 UTC 2006 i686 GNU/Linux
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
> JOTM 2.0.10
> JUnit 3.8.1
>            Reporter: Carsten Krebs
>             Fix For: 2.0.0.BETA1
>
>         Attachments: MultithreadedTxTest.java
>
>
> The unit test below reproduces "occasional" IllegalStateExceptions (s.b.) on commiting a transaction.  This test tries to modify the same node at the same time by different threads in different transactions using the optimistic locking scheme.
> java.lang.IllegalStateException: there is already a writer holding the lock: GlobalTransaction:<null>:43
> 	at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:96)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:204)
> 	at org.jboss.cache.Node.acquireWriteLock(Node.java:431)
> 	at org.jboss.cache.Node.acquire(Node.java:386)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:149)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:76)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
> 	at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
> 	at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
> 	at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1487)
> 	at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:416)
> 	at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:239)
> 	at OptimisticLockingTest$Worker.run(OptimisticLockingTest.java:135)
> The Cache Config:
> -------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <server>
>     <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
> 		<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>	
>         <attribute name="CacheMode">LOCAL</attribute>
>     </mbean>
> </server>   
> The Unit Test:
> -------------------
> import javax.transaction.Transaction;
> import javax.transaction.TransactionManager;
> import junit.framework.TestCase;
> import org.jboss.cache.CacheException;
> import org.jboss.cache.PropertyConfigurator;
> import org.jboss.cache.TransactionManagerLookup;
> import org.jboss.cache.TreeCache;
> import org.objectweb.jotm.Current;
> import EDU.oswego.cs.dl.util.concurrent.CyclicBarrier;
> /**
>  * OptimisticLockingTest
>  */
> public class OptimisticLockingTest extends TestCase {
> 	private static final String NODE_PATH = "/path/node";
> 	private static final String KEY = "key";
> 	private static final Current jotm = new Current();
> 	private TreeCache cache;
> 	protected void setUp() throws Exception {
> 		super.setUp();
> 		cache = new TreeCache();
> 		final PropertyConfigurator config = new PropertyConfigurator();
> 		cache.setTransactionManagerLookup(new TransactionManagerLookup() {
> 			public TransactionManager getTransactionManager() throws Exception {
> 				return Current.getTransactionManager();
> 			}
> 		});
> 		config.configure(cache, this.getClass().getResourceAsStream(
> 				"/cache-config.xml"));
> 		cache.startService();
> 	}
> 	public void testSimultanWrite() throws Exception {
> 		for (int i = 2; i < 20; i++) {
> 			System.out.println(">> testing simultaneous writes with " + i
> 					+ " threads...");
> 			testSimultanWrite(i);
> 		}
> 	}
> 	public void testSimultanWrite(final int _numThreads) throws Exception {
> 		final CyclicBarrier barrier = new CyclicBarrier(_numThreads);
> 		Worker[] workers = new Worker[_numThreads];
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i] = new Worker();
> 			workers[i].barrier = barrier;
> 			workers[i].value = "worker" + i;
> 			if (i == 0) {
> 				workers[i].isMaster = true;
> 			}
> 			workers[i].start();
> 		}
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i].join();
> 		}
> 		assertNull(workers[0].exception);
> 		for (int i = 0; i < workers.length; i++) {
> 			assertNull("rollback failed", workers[i].rollbackException);
> 		}
> 		for (int i = 1; i < workers.length; i++) {
> 			assertNotNull("missing exception", workers[i].exception);
> 			assertTrue("exception is not of type CacheException",
> 					workers[i].exception.getCause() instanceof CacheException);
> 		}
> 		assertEquals("worker0", cache.get(NODE_PATH, KEY));
> 		cache.getTransactionManager().begin();
> 		cache.remove(NODE_PATH);
> 		cache.getTransactionManager().commit();
> 	}
> 	private class Worker extends Thread {
> 		private CyclicBarrier barrier;
> 		private Exception exception;
> 		private Exception rollbackException;
> 		private String value;
> 		private boolean isMaster;
> 		/**
> 		 * @see java.lang.Thread#run()
> 		 */
> 		public void run() {
> 			final TransactionManager txManager = cache.getTransactionManager();
> 			Transaction tx = null;
> 			try {
> 				// wait for all threads started
> 				barrier.barrier();
> 				if (isMaster) {
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// lets the other threads start writing
> 					barrier.barrier();
> 					// wait for other threads to their modification
> 					barrier.barrier();
> 					// commit first
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 					// lets the other threads commit
> 					barrier.barrier();
> 				} else {
> 					// wait for master to start transaction
> 					barrier.barrier();
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// signal modification
> 					barrier.barrier();
> 					// wait for master to commit transaction
> 					barrier.barrier();
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 				}
> 			} catch (Exception e) {
> 				exception = e;
> 				try {
> 					tx.rollback();
> 				} catch (Exception e1) {
> 					rollbackException = e1;
> 				}
> 			}
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-806) Invalidation
 causes problems
 with otimistic data versioning and certain edge cases
In-Reply-To: <10131954.1160555681818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27955589.1185993297620.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-806?page=all ]

Manik Surtani reopened JBCACHE-806:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Invalidation causes problems with otimistic data versioning and certain edge cases
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-806
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-806
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0.SP1
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA, 1.4.1.GA
>
>         Attachments: OptimisticAsyncInvalidationTest.java, OptimisticSyncInvalidationTest.java
>
>
> Related to JBCACHE-793, but that has more to do with fixing the recommended configurations.
> From email conversations:
> Manik >>
> At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB.  If CacheB has V2 already, the invalidation will fail.  What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory.  Am I correct?
> Max >>
> It wasn't the scenario I had in mind, but this one is probably also relevant.
> Manik >>
> Or is the scenario you're trying to paint more like:
> V2 put into CacheA.  CacheB has V1, gets the invalidation msg, and V1 is evicted.  Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache?  This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache.
> Max >>
> This is the scenario I had in mind yes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-833) Redundant lock in
	cache loader
In-Reply-To: <23674490.1162796741672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28950381.1185993297799.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-833?page=all ]

Manik Surtani reopened JBCACHE-833:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Redundant lock in cache loader
> ------------------------------
>
>                 Key: JBCACHE-833
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-833
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.4.0.SP1
>            Reporter: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> Currently in CacheLoader, it calls "lock" from loadIfNeeded method. The "lock" method in turns invokes 
> TreeCache.java
>    public void _lock(Fqn fqn, DataNode.LockType lock_type, boolean recursive)
>            throws TimeoutException, LockingException
>    {
>       log.warn("method _lock() should not be invoked on TreeCache");
>    }
> I think the LockInterceptor should take care of the locking properly. So this call should be deprecated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-839) PojoCache to add
 an option to replicate final field
In-Reply-To: <6374929.1162975184638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28612273.1185993298036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-839?page=all ]

Manik Surtani reopened JBCACHE-839:
-----------------------------------

      Assignee:     (was: Jason T. Greene)
             

> PojoCache to add an option to replicate final field
> ---------------------------------------------------
>
>                 Key: JBCACHE-839
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-839
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>             Fix For: 2.0.0.GA
>
>
> We should add a flag to enable replication of final field in PojoCache. This can be done via pojocache-aop.xml, where:
>    <!-- Begining of interceptor chain -->
>    <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor"
>                 scope="PER_INSTANCE">
>       <!-- If set to true, will also replicate final field. -->
>          <attribute name="ReplicateFinalField">true</attribute>
>     </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 lists.jboss.org  Wed Aug  1 14:34:58 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-853) CacheJmxWrapper
 should implement NotificationBroadcaster
In-Reply-To: <28775885.1163711081674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9155797.1185993298198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-853?page=all ]

Manik Surtani reopened JBCACHE-853:
-----------------------------------

      Assignee:     (was: Brian Stansberry)
             

> CacheJmxWrapper should implement NotificationBroadcaster
> --------------------------------------------------------
>
>                 Key: JBCACHE-853
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-853
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.GA
>
>
> We need to clarify responsibility for this between the top level JMX wrapper beans and CacheMgmtInterceptor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:58 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-877) TreeCache usage
 should not depend on trove.jar
In-Reply-To: <25606358.1164359621709.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23618632.1185993298782.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-877?page=all ]

Manik Surtani reopened JBCACHE-877:
-----------------------------------

      Assignee:     (was: Galder Zamarreno)
             

> TreeCache usage should not depend on trove.jar
> ----------------------------------------------
>
>                 Key: JBCACHE-877
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-877
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 2.0.0.BETA1, 1.4.1.SP2
>            Reporter: Galder Zamarreno
>            Priority: Minor
>             Fix For: 2.0.0.CR1
>
>         Attachments: jbosscache.log
>
>
> A customer is upgrading from JBC 1.1 to 1.4.0.SP1 and 
> even though it only uses plain TreeCache, it gets a 
> NoClassDefFoundError for trove classes.
> 2006-11-23 13:19:03,781  ERROR RpcDispatcher exception=java.lang.NoClassDefFoundError: gnu/trove/TObjectHashingStrategy
> This is a TreeCacheAop/PojoCache dependency and therefore,
> should be isolated and attempted to be loaded only when 
> PojoCache 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 lists.jboss.org  Wed Aug  1 14:34:59 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-882) Migrating JBC 1.x
 java serialized data to 2.x VAM format
In-Reply-To: <23712522.1164720235826.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7607334.1185993299683.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-882?page=all ]

Manik Surtani reopened JBCACHE-882:
-----------------------------------

      Assignee:     (was: Galder Zamarreno)
             

> Migrating JBC 1.x java serialized data to 2.x VAM format
> --------------------------------------------------------
>
>                 Key: JBCACHE-882
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-882
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.ALPHA1
>            Reporter: Galder Zamarreno
>             Fix For: 2.0.0.BETA2, 2.0.0.GA
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Write an FAQ entry in which to explain how to transform 
> data stored in 1.x format into the VAM format.
> Explanation will focus on: "Write a 'bridge' app, which 
> starts 2 instances of JBC (old and new -  can these even 
> run in the same VM together?) and yanks data out of 
> one and into the other?"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:59 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-885) Bug when calling
 putObject() with array as argument
In-Reply-To: <23372676.1164808257741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10002321.1185993299834.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-885?page=all ]

Manik Surtani reopened JBCACHE-885:
-----------------------------------

      Assignee:     (was: Ben Wang)
             

> Bug when calling putObject() with array as argument
> ---------------------------------------------------
>
>                 Key: JBCACHE-885
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-885
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Bela Ban
>             Fix For: 2.0.0.ALPHA2
>
>
> Should at least not lead to an exception, we could for example state that we don't support arrays yet.
> To reproduce:
> TreeCacheAop cache;
> long arr=new long[]{1,2};
> cache.putObject("arr", arr);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:34:59 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:34:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-912) Fix tutorial
In-Reply-To: <9853821.1166635899738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24213981.1185993299934.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-912?page=all ]

Manik Surtani reopened JBCACHE-912:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Fix tutorial
> ------------
>
>                 Key: JBCACHE-912
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-912
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>             Fix For: 1.4.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 lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-995) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
In-Reply-To: <14344696.1172881209074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1884646.1185993300061.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-995?page=all ]

Manik Surtani reopened JBCACHE-995:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-995
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-995
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Rajesh Rajasekaran
>             Fix For: 2.0.0.BETA2
>
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-996) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
Message-ID: <10017690.1185993300201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-996?page=all ]

Manik Surtani reopened JBCACHE-996:
-----------------------------------

      Assignee:     (was: Manik Surtani)
             

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-996
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-996
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Rajesh Rajasekaran
>             Fix For: 2.0.0.BETA2
>
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest 
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1030) CR1 Build
 failing - aopc now requires concurrent.jar
In-Reply-To: <7016274.1177089570271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32355333.1185993300366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1030?page=all ]

Manik Surtani reopened JBCACHE-1030:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> CR1 Build failing - aopc now requires concurrent.jar
> ----------------------------------------------------
>
>                 Key: JBCACHE-1030
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1030
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA2
>         Environment: windows ant 1.6.5
>            Reporter: Bill Middleton
>             Fix For: 2.0.0.CR1
>
>
> The aop.InterceptionMarkers.<init> fails during the build of aopc-pojocache, due to the lack of ConcurrentReaderHashMap (from oswego).  Placing a copy of concurrent.jar into $JBOSS_CACHE/lib fixes the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1083) Look at inlining
 MarshalledValue, etc. and ditching jboss-common.jar
In-Reply-To: <28557342.1180602068355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28776053.1185993300457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1083?page=all ]

Manik Surtani reopened JBCACHE-1083:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> Look at inlining MarshalledValue, etc. and ditching jboss-common.jar
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-1083
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1083
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.CR1
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA, 2.0.0.CR3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1107) All notifier
 calls to be in a separate thread
In-Reply-To: <25158705.1181750831742.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31199428.1185993300572.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1107?page=all ]

Manik Surtani reopened JBCACHE-1107:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> All notifier calls to be in a separate thread
> ---------------------------------------------
>
>                 Key: JBCACHE-1107
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1107
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>             Fix For: 2.0.0.GA, 2.0.0.CR3
>
>
> Using an executor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1108) Move
 CacheListeners to their own thread pool
In-Reply-To: <21972953.1181751071690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11769361.1185993300720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1108?page=all ]

Manik Surtani reopened JBCACHE-1108:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> Move CacheListeners to their own thread pool
> --------------------------------------------
>
>                 Key: JBCACHE-1108
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1108
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>             Fix For: 2.0.0.CR3
>
>
> User CacheListeners should be dispatched in their own thread pool to prevent reentrancy problems and delays on cache operations. 
> Evection listeners should still be executed in the app thread.
> -Jason

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1140) JGroups MBeans
 should be bound to JMX if JBC MBeans are bound as well
In-Reply-To: <25932628.1184617847035.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13324175.1185993300815.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1140?page=all ]

Manik Surtani reopened JBCACHE-1140:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> JGroups MBeans should be bound to JMX if JBC MBeans are bound as well
> ---------------------------------------------------------------------
>
>                 Key: JBCACHE-1140
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1140
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP3
>            Reporter: Manik Surtani
>             Fix For: 1.4.1.SP4
>
>
> Forum ref posted is not specific to this case, but here is a comment to this effect by Bela pretty early in the thread.
> http://wiki.jboss.org/wiki/Wiki.jsp?page=JMX

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1149) FIFOPolicy is
 adding a visited node to the evictionqueue
In-Reply-To: <8548353.1185183227344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5369877.1185993300946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1149?page=all ]

Manik Surtani reopened JBCACHE-1149:
------------------------------------

      Assignee:     (was: Manik Surtani)
             

> FIFOPolicy is adding a visited node to the evictionqueue
> --------------------------------------------------------
>
>                 Key: JBCACHE-1149
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1149
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eviction, MonthOfBugs_200
>    Affects Versions: 2.0.0.CR2
>         Environment: OS: WIn XP SP2; JBOSS AS: 4.0.3; Cache : 2.0.0CR2
>            Reporter: Maddulety Vankadara
>             Fix For: 2.0.0.GA
>
>
> Created Eviction Policy with the following config:
>       <attribute name="EvictionPolicyConfig">
>          <config>
>             <attribute name="wakeUpIntervalSeconds">30</attribute>
>             <attribute name="eventQueueSize">200000</attribute>
>             <!-- Cache wide default -->
>             <region name="/_default_" policyClass="org.jboss.cache.eviction.FIFOPolicy">
>                <attribute name="maxNodes">500</attribute>
>             </region>
>          </config>
>       </attribute>
> And then created a region programmatically and assigned FIFOPolicy to that region.
> FIFOConfiguration evictionConfig = new FIFOConfiguration();
> evictionConfig.setMaxNodes(CacheConstants.60);
> Region rn = getCache().getRegion(Fqn.fromString("\a\b\c"), true);
> rn.setEvictionPolicy(evictionConfig);
> Add some nodes under "/a/b/c". All nodes are added to the evictionqueue properly. 
> But when I traverse  the region /a/b/c,  This node is also added to the evictionqueue and when the queue reaches the limit "MAXNodes"( which is 60 here), the node /a/b/c is evicted from cache.
> I think a visted node should not be evicted in a FIFO policy. 
> After going through the code, I noticed that VISIT_NODE_EVENT is not ignored in the FIFOPolicy class.
> Overriding the bemow method in org.jboss.cache.eviction.FIFOPolicy will fix the issue:
> public boolean canIgnoreEvent(Fqn fqn, NodeEventType eventType) {
>          return (eventType == NodeEventType.VISIT_NODE_EVENT);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11054721.1185993301112.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani updated JBCACHE-739:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 1.4.1.GA)

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:35:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-912) Fix tutorial
In-Reply-To: <9853821.1166635899738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30905318.1185993301215.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-912?page=all ]

Manik Surtani updated JBCACHE-912:
----------------------------------

    Fix Version/s:     (was: 1.4.1.GA)

> Fix tutorial
> ------------
>
>                 Key: JBCACHE-912
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-912
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:35:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-806) Invalidation
 causes problems
 with otimistic data versioning and certain edge cases
In-Reply-To: <10131954.1160555681818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14399936.1185993301468.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-806?page=all ]

Manik Surtani updated JBCACHE-806:
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 1.4.1.GA)

> Invalidation causes problems with otimistic data versioning and certain edge cases
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-806
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-806
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0.SP1
>            Reporter: Manik Surtani
>         Attachments: OptimisticAsyncInvalidationTest.java, OptimisticSyncInvalidationTest.java
>
>
> Related to JBCACHE-793, but that has more to do with fixing the recommended configurations.
> From email conversations:
> Manik >>
> At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB.  If CacheB has V2 already, the invalidation will fail.  What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory.  Am I correct?
> Max >>
> It wasn't the scenario I had in mind, but this one is probably also relevant.
> Manik >>
> Or is the scenario you're trying to paint more like:
> V2 put into CacheA.  CacheB has V1, gets the invalidation msg, and V1 is evicted.  Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache?  This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache.
> Max >>
> This is the scenario I had in mind yes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:37:02 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2170265.1185993422331.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani closed JBCACHE-739.
---------------------------------

    Resolution: Done

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:37:02 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25968581.1185993422564.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani reopened JBCACHE-739:
-----------------------------------

             

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:37:02 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-739) Exception in a
 CacheLoader
 throws ChainingCacheLoader calling method and prevent the call to the next
 CacheLoaders
In-Reply-To: <3869647.1155818437844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14481903.1185993422749.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-739?page=all ]

Manik Surtani closed JBCACHE-739.
---------------------------------

    Resolution: Rejected

> Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders 
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-739
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-739
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: shimi k
>
> All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. 
> public void put(Fqn name, Map attributes) throws Exception
>     {
>         Iterator i = writeCacheLoaders.iterator();
>         while (i.hasNext())
>         {
>             CacheLoader l = (CacheLoader) i.next();
>             l.put(name, attributes); 
>         }
>     }
> Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:38:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-806) Invalidation causes
 problems with otimistic data versioning and certain edge cases
In-Reply-To: <10131954.1160555681818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27927410.1185993529596.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-806?page=all ]

Manik Surtani closed JBCACHE-806.
---------------------------------

    Resolution: Duplicate Issue

JBCACHE-1155

> Invalidation causes problems with otimistic data versioning and certain edge cases
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-806
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-806
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0.SP1
>            Reporter: Manik Surtani
>         Attachments: OptimisticAsyncInvalidationTest.java, OptimisticSyncInvalidationTest.java
>
>
> Related to JBCACHE-793, but that has more to do with fixing the recommended configurations.
> From email conversations:
> Manik >>
> At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB.  If CacheB has V2 already, the invalidation will fail.  What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory.  Am I correct?
> Max >>
> It wasn't the scenario I had in mind, but this one is probably also relevant.
> Manik >>
> Or is the scenario you're trying to paint more like:
> V2 put into CacheA.  CacheB has V1, gets the invalidation msg, and V1 is evicted.  Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache?  This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache.
> Max >>
> This is the scenario I had in mind yes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:38:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-912) Fix tutorial
In-Reply-To: <9853821.1166635899738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1237410.1185993529723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-912?page=all ]

Manik Surtani closed JBCACHE-912.
---------------------------------

    Resolution: Rejected

> Fix tutorial
> ------------
>
>                 Key: JBCACHE-912
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-912
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:40:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-543) Consider
 synchronized(this) instead of a separate lock
Message-ID: <11445464.1185993649404.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-543?page=all ]

Manik Surtani closed JBCACHE-543.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.ALPHA2)
       Resolution: Rejected

> Consider synchronized(this) instead of a separate lock
> ------------------------------------------------------
>
>                 Key: JBCACHE-543
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-543
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>
> This will save one object per node, not a big deal but something.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:40:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-546) Move lock related
 operations to a separate utility, such as NodeLock
Message-ID: <21742107.1185993649530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-546?page=all ]

Manik Surtani closed JBCACHE-546.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.ALPHA2)
       Resolution: Rejected

> Move lock related operations to a separate utility, such as NodeLock
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-546
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-546
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>
> This is to reduce the amount of methods in Node to keep them fairly succinct.
> The lock in a Node itself could be package-protected so that interactions must happen through 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 lists.jboss.org  Wed Aug  1 14:40:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-885) Bug when calling
 putObject() with array as argument
In-Reply-To: <23372676.1164808257741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1315859.1185993649698.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-885?page=all ]

Manik Surtani closed JBCACHE-885.
---------------------------------

    Fix Version/s:     (was: 2.0.0.ALPHA2)
       Resolution: Rejected

> Bug when calling putObject() with array as argument
> ---------------------------------------------------
>
>                 Key: JBCACHE-885
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-885
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Bela Ban
>
> Should at least not lead to an exception, we could for example state that we don't support arrays yet.
> To reproduce:
> TreeCacheAop cache;
> long arr=new long[]{1,2};
> cache.putObject("arr", arr);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-740) Optimistic Locking
 Scheme: Occasional IllegalStateExceptions on commit
In-Reply-To: <30375980.1155931121396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <915685.1185993769479.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-740?page=all ]

Manik Surtani closed JBCACHE-740.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA1)
       Resolution: Cannot Reproduce Bug

> Optimistic Locking Scheme: Occasional IllegalStateExceptions on commit
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-740
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-740
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.GA
>         Environment: Linux 2.6.15-26-686 #1 SMP PREEMPT Thu Aug 3 03:13:28 UTC 2006 i686 GNU/Linux
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
> JOTM 2.0.10
> JUnit 3.8.1
>            Reporter: Carsten Krebs
>         Attachments: MultithreadedTxTest.java
>
>
> The unit test below reproduces "occasional" IllegalStateExceptions (s.b.) on commiting a transaction.  This test tries to modify the same node at the same time by different threads in different transactions using the optimistic locking scheme.
> java.lang.IllegalStateException: there is already a writer holding the lock: GlobalTransaction:<null>:43
> 	at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:96)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:204)
> 	at org.jboss.cache.Node.acquireWriteLock(Node.java:431)
> 	at org.jboss.cache.Node.acquire(Node.java:386)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:149)
> 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:76)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
> 	at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
> 	at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
> 	at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1487)
> 	at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:416)
> 	at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:239)
> 	at OptimisticLockingTest$Worker.run(OptimisticLockingTest.java:135)
> The Cache Config:
> -------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <server>
>     <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
> 		<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>	
>         <attribute name="CacheMode">LOCAL</attribute>
>     </mbean>
> </server>   
> The Unit Test:
> -------------------
> import javax.transaction.Transaction;
> import javax.transaction.TransactionManager;
> import junit.framework.TestCase;
> import org.jboss.cache.CacheException;
> import org.jboss.cache.PropertyConfigurator;
> import org.jboss.cache.TransactionManagerLookup;
> import org.jboss.cache.TreeCache;
> import org.objectweb.jotm.Current;
> import EDU.oswego.cs.dl.util.concurrent.CyclicBarrier;
> /**
>  * OptimisticLockingTest
>  */
> public class OptimisticLockingTest extends TestCase {
> 	private static final String NODE_PATH = "/path/node";
> 	private static final String KEY = "key";
> 	private static final Current jotm = new Current();
> 	private TreeCache cache;
> 	protected void setUp() throws Exception {
> 		super.setUp();
> 		cache = new TreeCache();
> 		final PropertyConfigurator config = new PropertyConfigurator();
> 		cache.setTransactionManagerLookup(new TransactionManagerLookup() {
> 			public TransactionManager getTransactionManager() throws Exception {
> 				return Current.getTransactionManager();
> 			}
> 		});
> 		config.configure(cache, this.getClass().getResourceAsStream(
> 				"/cache-config.xml"));
> 		cache.startService();
> 	}
> 	public void testSimultanWrite() throws Exception {
> 		for (int i = 2; i < 20; i++) {
> 			System.out.println(">> testing simultaneous writes with " + i
> 					+ " threads...");
> 			testSimultanWrite(i);
> 		}
> 	}
> 	public void testSimultanWrite(final int _numThreads) throws Exception {
> 		final CyclicBarrier barrier = new CyclicBarrier(_numThreads);
> 		Worker[] workers = new Worker[_numThreads];
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i] = new Worker();
> 			workers[i].barrier = barrier;
> 			workers[i].value = "worker" + i;
> 			if (i == 0) {
> 				workers[i].isMaster = true;
> 			}
> 			workers[i].start();
> 		}
> 		for (int i = 0; i < workers.length; i++) {
> 			workers[i].join();
> 		}
> 		assertNull(workers[0].exception);
> 		for (int i = 0; i < workers.length; i++) {
> 			assertNull("rollback failed", workers[i].rollbackException);
> 		}
> 		for (int i = 1; i < workers.length; i++) {
> 			assertNotNull("missing exception", workers[i].exception);
> 			assertTrue("exception is not of type CacheException",
> 					workers[i].exception.getCause() instanceof CacheException);
> 		}
> 		assertEquals("worker0", cache.get(NODE_PATH, KEY));
> 		cache.getTransactionManager().begin();
> 		cache.remove(NODE_PATH);
> 		cache.getTransactionManager().commit();
> 	}
> 	private class Worker extends Thread {
> 		private CyclicBarrier barrier;
> 		private Exception exception;
> 		private Exception rollbackException;
> 		private String value;
> 		private boolean isMaster;
> 		/**
> 		 * @see java.lang.Thread#run()
> 		 */
> 		public void run() {
> 			final TransactionManager txManager = cache.getTransactionManager();
> 			Transaction tx = null;
> 			try {
> 				// wait for all threads started
> 				barrier.barrier();
> 				if (isMaster) {
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// lets the other threads start writing
> 					barrier.barrier();
> 					// wait for other threads to their modification
> 					barrier.barrier();
> 					// commit first
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 					// lets the other threads commit
> 					barrier.barrier();
> 				} else {
> 					// wait for master to start transaction
> 					barrier.barrier();
> 					txManager.begin();
> 					cache.put(NODE_PATH, KEY, value);
> 					// signal modification
> 					barrier.barrier();
> 					// wait for master to commit transaction
> 					barrier.barrier();
> 					tx = txManager.getTransaction();
> 					tx.commit();
> 				}
> 			} catch (Exception e) {
> 				exception = e;
> 				try {
> 					tx.rollback();
> 				} catch (Exception e1) {
> 					rollbackException = e1;
> 				}
> 			}
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1140) JGroups MBeans
 should be bound to JMX if JBC MBeans are bound as well
In-Reply-To: <25932628.1184617847035.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17076396.1185993769703.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1140?page=all ]

Manik Surtani closed JBCACHE-1140.
----------------------------------

    Fix Version/s:     (was: 1.4.1.SP4)
       Resolution: Cannot Reproduce Bug

> JGroups MBeans should be bound to JMX if JBC MBeans are bound as well
> ---------------------------------------------------------------------
>
>                 Key: JBCACHE-1140
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1140
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP3
>            Reporter: Manik Surtani
>
> Forum ref posted is not specific to this case, but here is a comment to this effect by Bela pretty early in the thread.
> http://wiki.jboss.org/wiki/Wiki.jsp?page=JMX

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-882) Migrating JBC 1.x
 java serialized data to 2.x VAM format
In-Reply-To: <23712522.1164720235826.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16945327.1185993769871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-882?page=all ]

Manik Surtani closed JBCACHE-882.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)
                       (was: 2.0.0.GA)
       Resolution: Rejected

> Migrating JBC 1.x java serialized data to 2.x VAM format
> --------------------------------------------------------
>
>                 Key: JBCACHE-882
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-882
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.ALPHA1
>            Reporter: Galder Zamarreno
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Write an FAQ entry in which to explain how to transform 
> data stored in 1.x format into the VAM format.
> Explanation will focus on: "Write a 'bridge' app, which 
> starts 2 instances of JBC (old and new -  can these even 
> run in the same VM together?) and yanks data out of 
> one and into the other?"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:42:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-996) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
Message-ID: <16511541.1185993770172.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-996?page=all ]

Manik Surtani closed JBCACHE-996.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)
       Resolution: Rejected

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-996
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-996
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Rajesh Rajasekaran
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest 
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:42:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:42:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-995) Test failure -
 org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
In-Reply-To: <14344696.1172881209074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23488809.1185993770019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-995?page=all ]

Manik Surtani closed JBCACHE-995.
---------------------------------

    Fix Version/s:     (was: 2.0.0.BETA2)
       Resolution: Rejected

> Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-995
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-995
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Rajesh Rajasekaran
>
> org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution.
> To reproduce:
> run ./build.sh dist.
> Unzip JBossCache-all-2.0.0.BETA1.zip
> Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest
>   <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523">
>     <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606
>         at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285)
>         at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> </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 lists.jboss.org  Wed Aug  1 14:44:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-877) TreeCache usage
 should not depend on trove.jar
In-Reply-To: <25606358.1164359621709.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18122084.1185993893976.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-877?page=all ]

Manik Surtani closed JBCACHE-877.
---------------------------------

    Fix Version/s:     (was: 2.0.0.CR1)
       Resolution: Rejected

> TreeCache usage should not depend on trove.jar
> ----------------------------------------------
>
>                 Key: JBCACHE-877
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-877
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 2.0.0.BETA1, 1.4.1.SP2
>            Reporter: Galder Zamarreno
>            Priority: Minor
>         Attachments: jbosscache.log
>
>
> A customer is upgrading from JBC 1.1 to 1.4.0.SP1 and 
> even though it only uses plain TreeCache, it gets a 
> NoClassDefFoundError for trove classes.
> 2006-11-23 13:19:03,781  ERROR RpcDispatcher exception=java.lang.NoClassDefFoundError: gnu/trove/TObjectHashingStrategy
> This is a TreeCacheAop/PojoCache dependency and therefore,
> should be isolated and attempted to be loaded only when 
> PojoCache 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 lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1030) CR1 Build failing
 - aopc now requires concurrent.jar
In-Reply-To: <7016274.1177089570271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13394092.1185993894128.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1030?page=all ]

Manik Surtani closed JBCACHE-1030.
----------------------------------

    Fix Version/s:     (was: 2.0.0.CR1)
       Resolution: Rejected

> CR1 Build failing - aopc now requires concurrent.jar
> ----------------------------------------------------
>
>                 Key: JBCACHE-1030
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1030
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.BETA2
>         Environment: windows ant 1.6.5
>            Reporter: Bill Middleton
>
> The aop.InterceptionMarkers.<init> fails during the build of aopc-pojocache, due to the lack of ConcurrentReaderHashMap (from oswego).  Placing a copy of concurrent.jar into $JBOSS_CACHE/lib fixes the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1083) Look at inlining
 MarshalledValue, etc. and ditching jboss-common.jar
In-Reply-To: <28557342.1180602068355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17718920.1185993894211.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1083?page=all ]

Manik Surtani closed JBCACHE-1083.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.CR3)
       Resolution: Rejected

> Look at inlining MarshalledValue, etc. and ditching jboss-common.jar
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-1083
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1083
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.CR1
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1107) All notifier calls
 to be in a separate thread
In-Reply-To: <25158705.1181750831742.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24931902.1185993894298.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1107?page=all ]

Manik Surtani closed JBCACHE-1107.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
                       (was: 2.0.0.CR3)
       Resolution: Rejected

> All notifier calls to be in a separate thread
> ---------------------------------------------
>
>                 Key: JBCACHE-1107
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1107
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>
> Using an executor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:44:54 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:44:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1108) Move
 CacheListeners to their own thread pool
In-Reply-To: <21972953.1181751071690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5802783.1185993894441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1108?page=all ]

Manik Surtani closed JBCACHE-1108.
----------------------------------

    Fix Version/s:     (was: 2.0.0.CR3)
       Resolution: Rejected

> Move CacheListeners to their own thread pool
> --------------------------------------------
>
>                 Key: JBCACHE-1108
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1108
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>
> User CacheListeners should be dispatched in their own thread pool to prevent reentrancy problems and delays on cache operations. 
> Evection listeners should still be executed in the app thread.
> -Jason

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-5) AOP HTTP session
 replication under Tomcat 5
Message-ID: <23023754.1185994010742.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-5?page=all ]

Manik Surtani closed JBCACHE-5.
-------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> AOP HTTP session replication under Tomcat 5
> -------------------------------------------
>
>                 Key: JBCACHE-5
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-5
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.GA
>            Reporter: Bela Ban
>   Original Estimate: 10 weeks
>  Remaining Estimate: 10 weeks
>
> - JBossCache with aop/aopc
>   - Implemented any required features to 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 lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-35) Externalize the
 buffer queue size in LRUAlgorithm
Message-ID: <23214965.1185994011104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-35?page=all ]

Manik Surtani closed JBCACHE-35.
--------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Externalize the buffer queue size in LRUAlgorithm
> -------------------------------------------------
>
>                 Key: JBCACHE-35
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-35
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>            Priority: Minor
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Currently, the LRUAlgorithm use a hard size of 5000 on the buffer queue to process node eviction. We should make this configurable so it can adapt to different enviornment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-115) beforeEviction()
	callback
Message-ID: <9107940.1185994011339.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-115?page=all ]

Manik Surtani closed JBCACHE-115.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> beforeEviction() callback
> -------------------------
>
>                 Key: JBCACHE-115
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-115
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.1
>            Reporter: Bela Ban
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-129) Ensure graceful
 handling of marshalling between different versions
Message-ID: <11618776.1185994011551.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-129?page=all ]

Manik Surtani closed JBCACHE-129.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Ensure graceful handling of marshalling between different versions
> ------------------------------------------------------------------
>
>                 Key: JBCACHE-129
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-129
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>
> backwards compatibility

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-131) Cache Loaders (when
 unshared, 
 and not used with eviction) Should Persist Transient State Upon Startup
Message-ID: <30975284.1185994011709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-131?page=all ]

Manik Surtani closed JBCACHE-131.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-131
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-131
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Jimmy Wilson
>            Priority: Minor
>         Attachments: TreeCache.zip
>
>
> Given the following single, unshared cache loader use case in the TreeCache documentation:
> "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store"
> A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability.
> I have modified TreeCache to handle this situation, and I will attach the modified code to 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 lists.jboss.org  Wed Aug  1 14:46:51 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-139) Node notification
 event that ecludes myself
Message-ID: <10160651.1185994011939.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-139?page=all ]

Manik Surtani closed JBCACHE-139.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Node notification event that ecludes myself
> -------------------------------------------
>
>                 Key: JBCACHE-139
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-139
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> It will be nice to have a notification mechanism that can exclude myself (who modifies the node in the first place). This is needed in cache invlidation, 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 lists.jboss.org  Wed Aug  1 14:46:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-154) Ability to request
 cache statisics
Message-ID: <13546384.1185994012096.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-154?page=all ]

Manik Surtani closed JBCACHE-154.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Ability to request cache statisics
> ----------------------------------
>
>                 Key: JBCACHE-154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>            Reporter: Rich Dredge
>
> It would be very helpful to retrieve stats about certain regions of the cache such as:
> - Hit/Miss ratio per region
> - Access counts
> - Number of nodes within a region

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-163) Consolidate jboss
 related libraries
Message-ID: <32979997.1185994012256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ]

Manik Surtani closed JBCACHE-163.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> 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
>            Priority: Minor
>   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 lists.jboss.org  Wed Aug  1 14:46:52 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-250) Hierarchical caches
 not working when using JBoss service
Message-ID: <1596682.1185994012806.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-250?page=all ]

Manik Surtani closed JBCACHE-250.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Hierarchical caches not working when using JBoss service
> --------------------------------------------------------
>
>                 Key: JBCACHE-250
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-250
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3
>            Reporter: Nimrod Rivier
>            Priority: Minor
>
>  
> I tried to configure a hierarchical cache, composed of a first-level memory-only cache, 
> and a second-level file-only cache. It seems not to work when I the caches are jboss services, 
> but works when I use plain classes. 
> Details: 
> The caches are created as follows: 
> TreeCacheMBean sCacheSecondLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName1, server); 
> TreeCacheMBean sCacheFirstLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName2, server); 
> LocalDelegatingCacheLoader sCacheLoader = new LocalDelegatingCacheLoader(sCacheSecondLevel.getInstance()); 
> sCacheFirstLevel.setCacheLoader(sCacheLoader); 
> I then insert elements into sCacheFirstLevel, and it seems they are not delegated into sCacheSecondLevel . 
> Adding the following did not help
> sCacheFirstLevel.stopService();
> sCacheFirstLevel.startService();
> sCacheSecondLevel.stopService();
> sCacheSecondLevel.startService();
> When I use the following code to create the caches, everything seems to work fine: 
> sCacheSecondLevel = new TreeCache(); 
> sCacheSecondLevel.setCacheLoaderClass"org.jboss.cache.loader.FileCacheLoader"); 
> Properties filecacheLoaderProperties = new Properties(); 
> filecacheLoaderProperties.put("location","c:\\temp\\cache\\requests"); 
> sCacheSecondLevel.setCacheLoaderConfig(filecacheLoaderProperties); 
> sCacheFirstLevel = new TreeCache(); 
> CacheLoader cacheLoader = new LocalDelegatingCacheLoader (sCacheSecondLevel); 
> sCacheFirstLevel.setCacheLoader(cacheLoader); 
> /* Configure the caches (removed) */ 
> sCacheSecondLevel.createService(); 
> sCacheSecondLevel.startService(); 
> sCacheFirstLevel.createService(); 
> sCacheFirstLevel.startService(); 
>  
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-270) Create a
 notification interceptor
Message-ID: <8189831.1185994013018.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-270?page=all ]

Manik Surtani closed JBCACHE-270.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Create a notification interceptor
> ---------------------------------
>
>                 Key: JBCACHE-270
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-270
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4beta
>            Reporter: Hany Mesha
>
> The need has arised to create a notification interceptor to handle the callbacks results from different method call events and interceptors emitted events.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-328) Move attributes and
 getters/setters to interceptors
Message-ID: <3749117.1185994013170.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ]

Manik Surtani closed JBCACHE-328.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> 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
>
> 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 lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-332) Webdav interface
 for accessing JBossCache
Message-ID: <21407812.1185994013310.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-332?page=all ]

Manik Surtani closed JBCACHE-332.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Webdav interface for accessing JBossCache
> -----------------------------------------
>
>                 Key: JBCACHE-332
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-332
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>
> Provide a webdav interface for JBossCache. This will enable access, e.g. from Windows Explorer. Any file dragged into a folder will be replicated 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 lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-347) Replay tx if tx is
 created implicitly and fails on commit
Message-ID: <17637401.1185994013394.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-347?page=all ]

Manik Surtani closed JBCACHE-347.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Replay tx if tx is created implicitly and fails on commit
> ---------------------------------------------------------
>
>                 Key: JBCACHE-347
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-347
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>
> With optimistic locking, we first check for an existing transaction, and if there isn't one, we implicitly start one. Before the method returns, if we started the tx ourselves, we make sure we commit it. 
> There is scope to 'replay' the tx a fixed number of times here if the commit fails.
> At the moment, if the developer explicitly starts a tx before any cache operations, the cache may throw a RollbackException if it is unable to commit. If the developer doesn't explicitly start a tx, the cache may fail silently if it is unable to commit, logging errors but not throwing any exceptions. So there is scope here for silent retries without changing usage semantics.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:53 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-431) Remove jboss-XXX
 JARs which contain Nested(Runtime)Exceptions
Message-ID: <15945694.1185994013593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-431?page=all ]

Manik Surtani closed JBCACHE-431.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Remove jboss-XXX JARs which contain Nested(Runtime)Exceptions
> -------------------------------------------------------------
>
>                 Key: JBCACHE-431
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-431
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-432)
 PropertyConfigurator:
 investigate how to implement parsing functionality without use of
 PropertyEditor
Message-ID: <27835803.1185994015179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-432?page=all ]

Manik Surtani closed JBCACHE-432.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> PropertyConfigurator: investigate how to implement parsing functionality without use of PropertyEditor
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-432
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-432
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1
>            Reporter: Bela Ban
>
> Can you look into whether this is feasible ? If not, can you move this issue to 1.4 ?
> If we could get rid of that class, we could remove jboss-common.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 lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-469) JGroups Channel
 reference to be obtained from a factory
Message-ID: <3875529.1185994015272.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-469?page=all ]

Manik Surtani closed JBCACHE-469.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> JGroups Channel reference to be obtained from a factory
> -------------------------------------------------------
>
>                 Key: JBCACHE-469
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-469
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>
> The JChannelFactory (will be available in JGroups 2.3 - see JGRP-112) should be used to get a channel instance.
> The JChannelFactory could be obtained by:
> 1) MBeanServer lookup (look up a JChannelFactoryMBean instance)
> JBossCache config will need:
> + JChannelFactoryMBean name
> + JGroups configured stack name
> JBossCache config will not need:
> - Cluster name
> - JGroups settings
> 2) JChannelFactory instantiation
> JBossCache config will need:
> + Cluster name
> + JGroups settings
> JBossCache config will not need:
> - JChannelFactoryMBean name
> - JGroups configured stack 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 lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-478) Translate docs into
	Italian
Message-ID: <17523596.1185994015352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-478?page=all ]

Manik Surtani closed JBCACHE-478.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Translate docs into Italian
> ---------------------------
>
>                 Key: JBCACHE-478
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-478
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: Manik Surtani
>            Priority: Minor
>
> Translating JBoss Cache documentation to Italian.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-508) JBossCache bechmark
 and performance tuning
Message-ID: <15831918.1185994015496.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-508?page=all ]

Manik Surtani closed JBCACHE-508.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> JBossCache bechmark and performance tuning
> ------------------------------------------
>
>                 Key: JBCACHE-508
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-508
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>
> I have created this task specifically to document our effort in the bechmark and performance tuning process. I am using this tool that I developed to do perf test:http://jira.jboss.com/jira/browse/JBCACHE-503
> Note this load test only emulates the http session pattern now.
> I will document the numbers here that I have found and discussed with Bela.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-519) Investigate why tx
 has a higher thruput than non-tx under perf test
Message-ID: <29212255.1185994015627.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-519?page=all ]

Manik Surtani closed JBCACHE-519.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Investigate why tx has  a higher thruput than non-tx under perf test
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-519
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-519
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>
> During the perf test, I have discovered that the throughput with tx is higher than the non-tx one. This is very puzzling. I have asked Scot Marlow to double check it for me. The same. 
> Machines are: dev09 and dev17.
> Here are some breakdown numbers:
> 1. Single thread, 3000 loops, 10 ms sleep interval.
> (a) no tx
> -----
> Total time spent (ms) per thread: 202921 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? false
> is: 14 requests/sec
> (b) tx
> ----
> Total time spent (ms) per thread: 200718 for 3000 loops
> Throughtput for this node with:
> threads = 1
> loops = 3000
> sleep interval = 10
> object list size = 100
> tranasaction? true
> is: 14 requests/sec
> 2. 100 threads, 0ms sleep interval
> (a) no tx
> -----
> Total time spent (ms) per thread: 49352 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? false
> is: 404 requests/sec
> -----
> Total time spent (ms) per thread: 61240 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 325 requests/sec
> -------- dev04
> Total time spent (ms) per thread: 78871 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? false
> is: 250 requests/sec
> (b) tx
> -----
> Total time spent (ms) per thread: 68770 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 0
> object list size = 100
> tranasaction? true
> is: 288 requests/sec
> ----
> Total time spent (ms) per thread: 74575 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 263 requests/sec
> --- dev04
> Total time spent (ms) per thread: 80648 for 400 loops
> Throughtput for this node with:
> threads = 50
> loops = 400
> sleep interval = 20
> object list size = 100
> tranasaction? true
> is: 242 requests/sec

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-544) Remove AbstractNode
	superclass
Message-ID: <21243550.1185994015752.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-544?page=all ]

Manik Surtani closed JBCACHE-544.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Remove AbstractNode superclass
> ------------------------------
>
>                 Key: JBCACHE-544
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-544
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Elias Ross
>
> If AbstractNode is not used anywhere, it's basically more code to maintain.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:55 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-553) JBossCache
	throughput II
Message-ID: <17725825.1185994015886.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-553?page=all ]

Manik Surtani closed JBCACHE-553.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> JBossCache throughput II
> ------------------------
>
>                 Key: JBCACHE-553
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-553
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Here are the results using the perf test to run our Atl clustering lab. The machines are: 2X 3.0GHZ Xeon, 4GB Ram, GBSwtich, dedicated, 140GB drive.
> The load condition are:
> 400 clients (total), no sleep, 7kbyte payload
> async:
> Cluster size, throughtput (req/sec)
> 8,                  1270 (8.9MB/sec)
> 4,                  1270
> 2,                  1400
> sync:
> Cluster size, throughtput (req/sec)
> 8,                  432 (3.0MB/sec)
> 4,                  480
> 2,                  700

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-562) Disable cache
 loader when no cacheloader class is specified
Message-ID: <12943774.1185994016051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-562?page=all ]

Manik Surtani closed JBCACHE-562.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Disable cache loader when no cacheloader class is specified
> -----------------------------------------------------------
>
>                 Key: JBCACHE-562
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-562
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Priority: Minor
>
> In 1.3, we support a new form of cacheloader config. However, it is incovenient to disable the cache loader (previously all we need is to specify cacheloaderclass to empty). We should also support this kind of semantics so we can disable it easily. I propose when do createcacheloader, we also check whether the class name is there or not to decide whether to go ahead. If not, we simply log an info 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-696) Look into
 JDBMCacheLoader
 details and potentially promote as a 'recommended' cache loader?
In-Reply-To: <5384804.1152867851629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30710497.1185994016150.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-696?page=all ]

Manik Surtani closed JBCACHE-696.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader?
> ------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-696
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-696
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.3.0.GA
>            Reporter: 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-708) EOF exception in
	TcpCacheLoader
In-Reply-To: <3434652.1153423391520.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32215013.1185994016300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-708?page=all ]

Manik Surtani closed JBCACHE-708.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> EOF exception in TcpCacheLoader
> -------------------------------
>
>                 Key: JBCACHE-708
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-708
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Manik Surtani
>
> Happens when a node in the cluster dies.  See last few postings in 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-710) FileCacheLoader
 passivation/activation produces recursive exception when loader.remove
 fails
In-Reply-To: <18265876.1153707611477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17059011.1185994016494.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-710?page=all ]

Manik Surtani closed JBCACHE-710.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
> --------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-710
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-710
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA
>            Reporter: Ben Wang
>            Priority: Minor
>
> I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
> In ActivationInterceptor.java, we have:
>             if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
>                if (n.hasChildren()) {
>                   if (allInitialized(n)) {
>                      log.debug("children all initialized");
>                      remove(fqn);
>                   }
>                } else if (loaderNoChildren(fqn)) {
>                   log.debug("no children " + n);
>                   remove(fqn);
>                }
>             }
>          }
>       }
>       return retval;
>    }
>    private void remove(Fqn fqn) throws Exception {
>       loader.remove(fqn);
>       cache.notifyNodeActivate(fqn, false);
>       if (cache.getUseInterceptorMbeans()&& statsEnabled)
>          m_activations++;
>    }
> problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g.,
> cache.get(fqn, key)
> to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion.
> A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid 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 lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-723) Proper collection
	rollback
In-Reply-To: <9144391.1154091011340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4368499.1185994016695.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-723?page=all ]

Manik Surtani closed JBCACHE-723.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Proper collection rollback
> --------------------------
>
>                 Key: JBCACHE-723
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-723
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>
> It is not properly yet via the undointerceptor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-833) Redundant lock in
	cache loader
In-Reply-To: <23674490.1162796741672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2259499.1185994016822.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-833?page=all ]

Manik Surtani closed JBCACHE-833.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> Redundant lock in cache loader
> ------------------------------
>
>                 Key: JBCACHE-833
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-833
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0.GA, 1.4.0.SP1
>            Reporter: Ben Wang
>            Priority: Minor
>
> Currently in CacheLoader, it calls "lock" from loadIfNeeded method. The "lock" method in turns invokes 
> TreeCache.java
>    public void _lock(Fqn fqn, DataNode.LockType lock_type, boolean recursive)
>            throws TimeoutException, LockingException
>    {
>       log.warn("method _lock() should not be invoked on TreeCache");
>    }
> I think the LockInterceptor should take care of the locking properly. So this call should be deprecated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:56 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-839) PojoCache to add an
 option to replicate final field
In-Reply-To: <6374929.1162975184638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12865116.1185994016983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-839?page=all ]

Manik Surtani closed JBCACHE-839.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> PojoCache to add an option to replicate final field
> ---------------------------------------------------
>
>                 Key: JBCACHE-839
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-839
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>
> We should add a flag to enable replication of final field in PojoCache. This can be done via pojocache-aop.xml, where:
>    <!-- Begining of interceptor chain -->
>    <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor"
>                 scope="PER_INSTANCE">
>       <!-- If set to true, will also replicate final field. -->
>          <attribute name="ReplicateFinalField">true</attribute>
>     </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 lists.jboss.org  Wed Aug  1 14:46:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-853) CacheJmxWrapper
 should implement NotificationBroadcaster
In-Reply-To: <28775885.1163711081674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22052583.1185994017156.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-853?page=all ]

Manik Surtani closed JBCACHE-853.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> CacheJmxWrapper should implement NotificationBroadcaster
> --------------------------------------------------------
>
>                 Key: JBCACHE-853
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-853
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>
> We need to clarify responsibility for this between the top level JMX wrapper beans and CacheMgmtInterceptor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:46:57 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:46:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1149) FIFOPolicy is
 adding a visited node to the evictionqueue
In-Reply-To: <8548353.1185183227344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11678473.1185994017396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1149?page=all ]

Manik Surtani closed JBCACHE-1149.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Rejected

> FIFOPolicy is adding a visited node to the evictionqueue
> --------------------------------------------------------
>
>                 Key: JBCACHE-1149
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1149
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eviction, MonthOfBugs_200
>    Affects Versions: 2.0.0.CR2
>         Environment: OS: WIn XP SP2; JBOSS AS: 4.0.3; Cache : 2.0.0CR2
>            Reporter: Maddulety Vankadara
>
> Created Eviction Policy with the following config:
>       <attribute name="EvictionPolicyConfig">
>          <config>
>             <attribute name="wakeUpIntervalSeconds">30</attribute>
>             <attribute name="eventQueueSize">200000</attribute>
>             <!-- Cache wide default -->
>             <region name="/_default_" policyClass="org.jboss.cache.eviction.FIFOPolicy">
>                <attribute name="maxNodes">500</attribute>
>             </region>
>          </config>
>       </attribute>
> And then created a region programmatically and assigned FIFOPolicy to that region.
> FIFOConfiguration evictionConfig = new FIFOConfiguration();
> evictionConfig.setMaxNodes(CacheConstants.60);
> Region rn = getCache().getRegion(Fqn.fromString("\a\b\c"), true);
> rn.setEvictionPolicy(evictionConfig);
> Add some nodes under "/a/b/c". All nodes are added to the evictionqueue properly. 
> But when I traverse  the region /a/b/c,  This node is also added to the evictionqueue and when the queue reaches the limit "MAXNodes"( which is 60 here), the node /a/b/c is evicted from cache.
> I think a visted node should not be evicted in a FIFO policy. 
> After going through the code, I noticed that VISIT_NODE_EVENT is not ignored in the FIFOPolicy class.
> Overriding the bemow method in org.jboss.cache.eviction.FIFOPolicy will fix the issue:
> public boolean canIgnoreEvent(Fqn fqn, NodeEventType eventType) {
>          return (eventType == NodeEventType.VISIT_NODE_EVENT);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:53:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-857) Upgrade to JBoss
 AOP 2.0.ALPHA2
In-Reply-To: <10223338.1163733821459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26059199.1185994429326.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-857?page=all ]

Manik Surtani reopened JBCACHE-857:
-----------------------------------

      Assignee: Manik Surtani  (was: Ben Wang)
             

> Upgrade to JBoss AOP 2.0.ALPHA2
> -------------------------------
>
>                 Key: JBCACHE-857
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-857
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> Temporarily upgrade to 2.0.ALPHA2 for the alpha release such tat we can continue integration into AS5.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-857) Upgrade to JBoss
	AOP 2.0.ALPHA2
In-Reply-To: <10223338.1163733821459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32668773.1185994566180.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-857?page=all ]

Manik Surtani closed JBCACHE-857.
---------------------------------

    Resolution: Rejected

> Upgrade to JBoss AOP 2.0.ALPHA2
> -------------------------------
>
>                 Key: JBCACHE-857
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-857
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>
> Temporarily upgrade to 2.0.ALPHA2 for the alpha release such tat we can continue integration into AS5.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-654) Upgrade to JBoss
 AOP 2.0 to prevent classloader memory leakage during re-deployment
Message-ID: <29364336.1185994566360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-654?page=all ]

Manik Surtani updated JBCACHE-654:
----------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

Moving to a release when AOP 2.0 will be avbl!

> Upgrade to JBoss AOP 2.0 to prevent classloader memory leakage during re-deployment
> -----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-654
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-654
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-967) Upgrade to
	JGroups 2.4.SP1
In-Reply-To: <671116.1170632843598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14111363.1185994566439.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-967?page=all ]

Manik Surtani reopened JBCACHE-967:
-----------------------------------

             

> Upgrade to JGroups 2.4.SP1
> --------------------------
>
>                 Key: JBCACHE-967
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-967
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.CR1
>
>
> This fixes MUX/State transfer test failures present with 2.4.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-967) Upgrade to JGroups
	2.4.SP1
In-Reply-To: <671116.1170632843598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1032053.1185994566515.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-967?page=all ]

Manik Surtani closed JBCACHE-967.
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)
                       (was: 2.0.0.BETA2)
       Resolution: Done

> Upgrade to JGroups 2.4.SP1
> --------------------------
>
>                 Key: JBCACHE-967
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-967
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.CR1
>
>
> This fixes MUX/State transfer test failures present with 2.4.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 lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-884) Upgrade to
	JGroups 2.4.1
In-Reply-To: <11844620.1164808136361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15806710.1185994566676.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-884?page=all ]

Manik Surtani reopened JBCACHE-884:
-----------------------------------

             

> Upgrade to JGroups 2.4.1
> ------------------------
>
>                 Key: JBCACHE-884
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-884
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.GA
>
>
> As a part of this, rely on JGroups ANYCAST (JBCACHE-813) properly, and yank out JBCACHE-813 kludge.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:56:06 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:56:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-884) Upgrade to JGroups
	2.4.1
In-Reply-To: <11844620.1164808136361.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25012075.1185994566780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-884?page=all ]

Manik Surtani closed JBCACHE-884.
---------------------------------

    Fix Version/s:     (was: 2.0.0.ALPHA2)
                       (was: 2.0.0.GA)
       Resolution: Done

> Upgrade to JGroups 2.4.1
> ------------------------
>
>                 Key: JBCACHE-884
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-884
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.GA
>
>
> As a part of this, rely on JGroups ANYCAST (JBCACHE-813) properly, and yank out JBCACHE-813 kludge.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-886) Upgrading from
 JGroups 2.2.9.2 to JGroups 2.4
In-Reply-To: <4570210.1164810896031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18859640.1185994669523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-886?page=all ]

Manik Surtani reopened JBCACHE-886:
-----------------------------------

             

> Upgrading from JGroups 2.2.9.2 to JGroups 2.4
> ---------------------------------------------
>
>                 Key: JBCACHE-886
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-886
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-886) Upgrading from
 JGroups 2.2.9.2 to JGroups 2.4
In-Reply-To: <4570210.1164810896031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30146199.1185994669674.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-886?page=all ]

Manik Surtani closed JBCACHE-886.
---------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Done

> Upgrading from JGroups 2.2.9.2 to JGroups 2.4
> ---------------------------------------------
>
>                 Key: JBCACHE-886
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-886
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1020) Upgrade to
	JGroups 2.5.BETA2
In-Reply-To: <12027656.1175601658413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17968570.1185994669783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1020?page=all ]

Manik Surtani reopened JBCACHE-1020:
------------------------------------

             

> Upgrade to JGroups 2.5.BETA2
> ----------------------------
>
>                 Key: JBCACHE-1020
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1020
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA2
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1020) Upgrade to JGroups
	2.5.BETA2
In-Reply-To: <12027656.1175601658413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12798251.1185994669875.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1020?page=all ]

Manik Surtani closed JBCACHE-1020.
----------------------------------

    Fix Version/s:     (was: 2.0.0.GA)
       Resolution: Done

> Upgrade to JGroups 2.5.BETA2
> ----------------------------
>
>                 Key: JBCACHE-1020
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1020
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 2.0.0.BETA2
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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 lists.jboss.org  Wed Aug  1 14:57:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-470) Update JBoss
 Cache to use JGroups 2.4 and Multiplexer
Message-ID: <21387539.1185994669965.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Manik Surtani reopened JBCACHE-470:
-----------------------------------

      Assignee: Manik Surtani  (was: Jerry Gauthier)
             

> 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: Manik Surtani
>            Priority: Blocker
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:59:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-470) Update JBoss Cache
 to use JGroups Multiplexer
Message-ID: <16927205.1185994789267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Manik Surtani updated JBCACHE-470:
----------------------------------

    Summary: Update JBoss Cache to use JGroups Multiplexer  (was: Update JBoss Cache to use JGroups 2.4 and Multiplexer)

> Update JBoss Cache to use JGroups 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: Manik Surtani
>            Priority: Blocker
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 14:59:49 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 1 Aug 2007 14:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-470) Update JBoss Cache
 to use JGroups Multiplexer
Message-ID: <14991776.1185994789350.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Manik Surtani closed JBCACHE-470.
---------------------------------

    Resolution: Done

> Update JBoss Cache to use JGroups 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: Manik Surtani
>            Priority: Blocker
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Wed Aug  1 15:24:49 2007
From: jira-events at lists.jboss.org (Hany Mesha (JIRA))
Date: Wed, 1 Aug 2007 15:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
In-Reply-To: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23534893.1185996289528.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3720?page=all ]

Hany Mesha resolved JBAS-3720.
------------------------------

    Resolution: Done
      Assignee: Brian Stansberry  (was: Hany Mesha)

changed the fqn for sessions map in TreeCacheSSOClusterManager 

The change is done in the following method:

private Fqn getSessionsFqn(String ssoid)
   {
      Object[] objs = new Object[]{SSO, ssoid, localAddress, SESSIONS};
      return new Fqn(objs);
   }

Note that the original fqn didn't have localAddress as part of the node structure in the tree cache. With this change the sessions associated with the SSO ID will be identified by the server that this SSO cluster manager running on.

Brian, Please confirm the change and close the issue. Thanks!

Due to the fact that the test suite is broken, I didn't have chance to test this change. However, there's no special test cases that need to be written to verify the change. So once the test suite is repaired, the verification would be running the SSO test cases to success.



> 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 lists.jboss.org  Wed Aug  1 15:36:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 1 Aug 2007 15:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1024) jndi multiplexer
 broken for list() and listBindings()
Message-ID: <11875388.1185997009377.JavaMail.jira@cloud.prod.atl2.jboss.com>

jndi multiplexer broken for list() and listBindings()
-----------------------------------------------------

                 Key: EJBTHREE-1024
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1024
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.0 GA
            Reporter: William DeCoste
         Assigned To: William DeCoste




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 15:36:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 1 Aug 2007 15:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1024) jndi multiplexer
 broken for list() and listBindings()
In-Reply-To: <11875388.1185997009377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28986639.1185997009556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1024?page=all ]

William DeCoste closed EJBTHREE-1024.
-------------------------------------

    Fix Version/s: AS 4.2.2.GA
       Resolution: Done

> jndi multiplexer broken for list() and listBindings()
> -----------------------------------------------------
>
>                 Key: EJBTHREE-1024
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1024
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.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 lists.jboss.org  Wed Aug  1 18:25:49 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 1 Aug 2007 18:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1050) Extra space
 between variable and field name in LHS causes crash
In-Reply-To: <11262114.1185887149714.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32083173.1186007149894.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1050?page=all ]

Edson Tirelli resolved JBRULES-1050.
------------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

Fixed.

Changed parser to ignore comments and white spaces when parsing nested accessors paths and qualified identifiers. Unit test added. Following expression is correctly parsed:

"org   .   drools/*comment*/\t  .Message( text not matches $c#comment\n. property )\n";
        assertEquals( "org.drools.Message", 
                      pat.getObjectType() );
        assertEquals( "not matches",
                      restr.getEvaluator() );
        assertEquals( "$c.property",
                      restr.getText() );
 
Thanks for reporting and providing test case. Fix will be included in 4.0.1.
 

> Extra space between variable and field name in LHS causes crash
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1050
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1050
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Writing a condition as "$co:Item(attachment in ($c, $c. parent))" fails at runtime with an uninformative exception. Removing the extra space and writing "$c.parent" corrects the problem.
> Below is the rule file, sample code and exception trace.
> package com.sample
>  
> import com.sample.DroolsTest.Child;
> import com.sample.DroolsTest.Parent;
> import com.sample.DroolsTest.Item;
>  
> rule "My Rule"
> 	
> 	when
> 		$c:Child()
> 		$co:Item(attachment in ($c, $c. parent))
> 	then
> 		System.out.println("wawa");
> end
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class DroolsTest {
> 	public static final void main(String[] args) {
> 		try {
> 			RuleBase ruleBase = readRule();
> 		} catch (Throwable t) {
> 			t.printStackTrace();
> 		}
> 	}
> 	private static RuleBase readRule() throws Exception {
> 		Reader source = new InputStreamReader(DroolsTest.class
> 				.getResourceAsStream("/Sample.drl"));
> 		PackageBuilder builder = new PackageBuilder();
> 		builder.addPackageFromDrl(source);
> 		Package pkg = builder.getPackage();
> 		RuleBase ruleBase = RuleBaseFactory.newRuleBase();
> 		ruleBase.addPackage(pkg);
> 		return ruleBase;
> 	}
> 	public static class Parent {
> 	}
> 	public static class Child {
> 		private Parent parent;
> 		public Parent getParent() {
> 			return parent;
> 		}
> 	}
> 	public static class Item {
> 		private Object attachment;
> 		public Object getAttachment() {
> 			return attachment;
> 		}
> 	}
> }
> java.lang.NullPointerException
> 	at org.drools.reteoo.builder.PatternBuilder.createConstraints(PatternBuilder.java:128)
> 	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:72)
> 	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:54)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:136)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:109)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:262)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:333)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:33)
> 	at com.sample.DroolsTest.main(DroolsTest.java:20)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 18:25:50 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 1 Aug 2007 18:25:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1046) Business Object
 returns null due to Shadow Fact, unless declared final
In-Reply-To: <32114281.1185807409476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10401934.1186007150379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1046?page=all ]

Edson Tirelli resolved JBRULES-1046.
------------------------------------

    Resolution: Done

I will close the ticket. If it is still an issue, please reopen.

> Business Object returns null due to Shadow Fact, unless declared final
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1046
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1046
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.MR3,  4.0.0.GA
>         Environment: Windows, X86 based machine
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> SCENARIO
> -----------------
> Define an Object 'BooleanConfiguration'
> public class BooleanConfiguration extends BusinessObject { 
>   String paramName; //with setter and getter
>   Boolean value; //with setter and getter
>   Client client; //with setter and getter -- Client is an object that composes of String clientId;
> }
> *BusinessObject is just a generic Object that maintains a reference to the Assertion List from where it came (Ref. to the container object, Collection).
> Action(s):
> -------------
> 1. initialize the object with a Parameter and Value (Hard code to test) -- Set
> 2. Execute against a Rule:
> When
>    config: BooleanConfiguration(value==true)
> Then
>   //Do something
> end
> EXECUTION NOTES:
> -------------------------------
> 1. I asserted this object and the rule was not executing as I expected.
> 2. I put a break point in the object, and found that it set it correctly but 
> whenenver the rule engine called the get method the vaue of the object was null.
> 3. I traced this the place where it creates shadows in Rete.java.
> I had observed a similar behaviour in version 3.1 or 3.6 (if there was a 3.6).
> it was more prolific then.
> 4. I made the class 'final' (This prevents a shadow from being created), and voila
> my rule worked as expected. 
> Note: None of the other objects needed a final, but had comeplex associations.
> But this particular object does not run, unless declared 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 lists.jboss.org  Wed Aug  1 19:54:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 1 Aug 2007 19:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1040) Multi-pattern
 accumulate support
In-Reply-To: <27334079.1185722987182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30141866.1186012489347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1040?page=all ]

Mark Proctor updated JBRULES-1040:
----------------------------------

    Fix Version/s: FUTURE

> Multi-pattern accumulate support
> --------------------------------
>
>                 Key: JBRULES-1040
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1040
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> [Edson said there might be already such an issue, but I couldn't find it looking through jira.]
> Something like this should be possible:
>   $multipleQueensHorizontal : Long()
>     from accumulate(
>         $q1 : Queen($id : id, $y : y);
>         Queen(id > $id, y == $y);
>       , count($q1)
>     );

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  1 19:56:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 1 Aug 2007 19:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31252455.1186012609359.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1048?page=comments#action_12370801 ] 
            
Mark Proctor commented on JBRULES-1048:
---------------------------------------

So context assist is working, with dslr as the extension. We still need to decide how to handle woolfel's changes. He says this is configurable, so we need to expose this in the IDE configuration, with the default as single sentences.

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Wed Aug  1 23:10:53 2007
From: jira-events at lists.jboss.org (zhang baoquan (JIRA))
Date: Wed, 1 Aug 2007 23:10:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1030) jbpmContext can't
	close
Message-ID: <30881023.1186024253983.JavaMail.jira@cloud.prod.atl2.jboss.com>

jbpmContext can't close
-----------------------

                 Key: JBPM-1030
                 URL: http://jira.jboss.com/jira/browse/JBPM-1030
             Project: JBoss jBPM
          Issue Type: Patch
          Components: Core Engine
    Affects Versions: jBPM jPDL 3.2
         Environment: win2000,tomcat,jbpm3.2,eclipse
            Reporter: zhang baoquan
         Assigned To: Tom Baeyens


Session hsession = jbpmContext.getSession();
try {            
            hsession.save(businessReport);
            ProcessDefinition pd = jbpmContext.getGraphSession().findLatestProcessDefinition("RNDFProcess");
            ProcessInstance pi = pd.createProcessInstance();
            //pi.getContextInstance().setVariable("username", from_username);
            TaskInstance ti = pi.getTaskMgmtInstance().createStartTaskInstance();
            jbpmContext.close();//here is exception
            ti.setVariable("report_id", businessReport.getReportId());
            ti.end();
} catch (Exception e) {
	System.out.println("Unknown error in the SaveGo().");
	e.printStackTrace();
	jbpmContext.setRollbackOnly();
}finally{
            jbpmContext.close();
}
exception:
09:36:53,328 [http8001-Processor22] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
09:36:53,328 [http8001-Processor22] DEBUG JbpmContext : creating org.jbpm.JbpmContext at 1ddf47e
09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceServiceFactory : creating persistence service
09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceService : creating hibernate session
09:36:53,343 [http8001-Processor22] DEBUG DbPersistenceService : beginning hibernate transaction
09:36:53,359 [http8001-Processor22] DEBUG GraphElement : event 'process-start' on 'ProcessDefinition(RNDFProcess)' for 'Token(/)'
09:36:53,359 [http8001-Processor22] WARN  StatefulPersistenceContext : Narrowing proxy to class org.jbpm.graph.node.StartState - this operation breaks ==
09:36:53,375 [http8001-Processor22] DEBUG TaskController : creating task instance variable 'report_id' from process variable 'report_id', value 'null'
09:36:53,375 [http8001-Processor22] DEBUG VariableContainer : create variable 'report_id' in 'TaskInstance[appendForm]' with value 'null'
09:36:53,375 [http8001-Processor22] DEBUG GraphElement : event 'task-create' on 'Task(appendForm)' for 'Token(/)'

09:36:56,203 [http8001-Processor22] DEBUG GraphElement : event 'task-assign' on 'Task(appendForm)' for 'Token(/)'
09:36:56,203 [http8001-Processor22] DEBUG JbpmContext : closing JbpmContext
09:36:56,203 [http8001-Processor22] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 9d478b
09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : committing hibernate transaction
09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate commit failed
org.hibernate.SessionException: Session is closed
	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
	at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:139)
	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:115)
	at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:253)
	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:211)
	at org.jbpm.svc.Services.close(Services.java:222)
	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
	at java.lang.Thread.run(Thread.java:595)
09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : rolling back hibernate transaction
09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate rollback failed
org.hibernate.SessionException: Session is closed
	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
	at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:183)
	at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)
	at org.jbpm.persistence.db.DbPersistenceService.rollback(DbPersistenceService.java:297)
	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:213)
	at org.jbpm.svc.Services.close(Services.java:222)
	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
	at java.lang.Thread.run(Thread.java:595)
09:36:56,203 [http8001-Processor22] WARN  DbPersistenceService : hibernate session was already closed
org.jbpm.persistence.JbpmPersistenceException: hibernate commit failed
	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:216)
	at org.jbpm.svc.Services.close(Services.java:222)
	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
	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 lists.jboss.org  Wed Aug  1 23:15:49 2007
From: jira-events at lists.jboss.org (zhang baoquan (JIRA))
Date: Wed, 1 Aug 2007 23:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1030) session closed
 before jbpmContext close
In-Reply-To: <30881023.1186024253983.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15891702.1186024549511.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1030?page=all ]

zhang baoquan updated JBPM-1030:
--------------------------------

    Summary: session closed before jbpmContext close  (was: jbpmContext can't close)

> session closed before jbpmContext close
> ---------------------------------------
>
>                 Key: JBPM-1030
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1030
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: win2000,tomcat,jbpm3.2,eclipse
>            Reporter: zhang baoquan
>         Assigned To: Tom Baeyens
>
> Session hsession = jbpmContext.getSession();
> try {            
>             hsession.save(businessReport);
>             ProcessDefinition pd = jbpmContext.getGraphSession().findLatestProcessDefinition("RNDFProcess");
>             ProcessInstance pi = pd.createProcessInstance();
>             //pi.getContextInstance().setVariable("username", from_username);
>             TaskInstance ti = pi.getTaskMgmtInstance().createStartTaskInstance();
>             jbpmContext.close();//here is exception
>             ti.setVariable("report_id", businessReport.getReportId());
>             ti.end();
> } catch (Exception e) {
> 	System.out.println("Unknown error in the SaveGo().");
> 	e.printStackTrace();
> 	jbpmContext.setRollbackOnly();
> }finally{
>             jbpmContext.close();
> }
> exception:
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContext : creating org.jbpm.JbpmContext at 1ddf47e
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceServiceFactory : creating persistence service
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceService : creating hibernate session
> 09:36:53,343 [http8001-Processor22] DEBUG DbPersistenceService : beginning hibernate transaction
> 09:36:53,359 [http8001-Processor22] DEBUG GraphElement : event 'process-start' on 'ProcessDefinition(RNDFProcess)' for 'Token(/)'
> 09:36:53,359 [http8001-Processor22] WARN  StatefulPersistenceContext : Narrowing proxy to class org.jbpm.graph.node.StartState - this operation breaks ==
> 09:36:53,375 [http8001-Processor22] DEBUG TaskController : creating task instance variable 'report_id' from process variable 'report_id', value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG VariableContainer : create variable 'report_id' in 'TaskInstance[appendForm]' with value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG GraphElement : event 'task-create' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG GraphElement : event 'task-assign' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG JbpmContext : closing JbpmContext
> 09:36:56,203 [http8001-Processor22] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 9d478b
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : committing hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate commit failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:139)
> 	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:115)
> 	at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:253)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:211)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : rolling back hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate rollback failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:183)
> 	at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)
> 	at org.jbpm.persistence.db.DbPersistenceService.rollback(DbPersistenceService.java:297)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:213)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] WARN  DbPersistenceService : hibernate session was already closed
> org.jbpm.persistence.JbpmPersistenceException: hibernate commit failed
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:216)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	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 lists.jboss.org  Thu Aug  2 01:11:58 2007
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Thu, 2 Aug 2007 01:11:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4589) Upgrade to JSF RI
	1.2_05
Message-ID: <2130135.1186031518237.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade to JSF RI 1.2_05
------------------------

                 Key: JBAS-4589
                 URL: http://jira.jboss.com/jira/browse/JBAS-4589
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.2.GA
            Reporter: Juergen Zimmermann


FYI: I ran my testsuite with JSF 1.2_05 RC1 and hadn't any problems.
The release notes can be found at https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_05/changelog.html

Citation: "Another change which may impact applications is that we've merged all
ServletContextListeners into one listener. In 1.2_04, we had three
separate listeners. If a container wasn't compliant in invoking listeners
defined in a TLD, the developer had to know all three of these. It seemed
to have been a mistake to have so many. The only listener to worry about
at this point is com.sun.faces.config.ConfigureListener."

ConfigureListener is just being used in org/jboss/web/jsf/integration/config/JBossJSFConfigureListener.java
So everything looks 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 lists.jboss.org  Thu Aug  2 01:33:58 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Thu, 2 Aug 2007 01:33:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1046) Business Object
 returns null due to Shadow Fact, unless declared final
In-Reply-To: <32114281.1185807409476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12653746.1186032838505.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1046?page=comments#action_12370812 ] 
            
Arjun Dhar commented on JBRULES-1046:
-------------------------------------

Thanks Edson. Will do some more analysis to ensure I can reproduce the problem for you. There is a lot of code so cant send it all, so will try and find it.

This is not a forum so wont ask a question, but related to you comment "lazy cached", even if it is lazy cached, it cant afford to be that lazy that when an object is called by the Rule, it still returns null. :o) Could that be the problem?

For now we are good. Thank you, appreciate it.

> Business Object returns null due to Shadow Fact, unless declared final
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1046
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1046
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.MR3,  4.0.0.GA
>         Environment: Windows, X86 based machine
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> SCENARIO
> -----------------
> Define an Object 'BooleanConfiguration'
> public class BooleanConfiguration extends BusinessObject { 
>   String paramName; //with setter and getter
>   Boolean value; //with setter and getter
>   Client client; //with setter and getter -- Client is an object that composes of String clientId;
> }
> *BusinessObject is just a generic Object that maintains a reference to the Assertion List from where it came (Ref. to the container object, Collection).
> Action(s):
> -------------
> 1. initialize the object with a Parameter and Value (Hard code to test) -- Set
> 2. Execute against a Rule:
> When
>    config: BooleanConfiguration(value==true)
> Then
>   //Do something
> end
> EXECUTION NOTES:
> -------------------------------
> 1. I asserted this object and the rule was not executing as I expected.
> 2. I put a break point in the object, and found that it set it correctly but 
> whenenver the rule engine called the get method the vaue of the object was null.
> 3. I traced this the place where it creates shadows in Rete.java.
> I had observed a similar behaviour in version 3.1 or 3.6 (if there was a 3.6).
> it was more prolific then.
> 4. I made the class 'final' (This prevents a shadow from being created), and voila
> my rule worked as expected. 
> Note: None of the other objects needed a final, but had comeplex associations.
> But this particular object does not run, unless declared 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 lists.jboss.org  Thu Aug  2 01:39:49 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Thu, 2 Aug 2007 01:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1046) Business Object
 returns null due to Shadow Fact, unless declared final
In-Reply-To: <32114281.1185807409476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16675079.1186033189399.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1046?page=comments#action_12370814 ] 
            
Arjun Dhar commented on JBRULES-1046:
-------------------------------------

sorry, the above was not intended to be a question, Just a thought. Will provide more emperical data to infer the correct problem, if it exists. Thanks again. We can close it, if I find conclusive data, will reopen this bug.

> Business Object returns null due to Shadow Fact, unless declared final
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1046
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1046
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.MR3,  4.0.0.GA
>         Environment: Windows, X86 based machine
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> SCENARIO
> -----------------
> Define an Object 'BooleanConfiguration'
> public class BooleanConfiguration extends BusinessObject { 
>   String paramName; //with setter and getter
>   Boolean value; //with setter and getter
>   Client client; //with setter and getter -- Client is an object that composes of String clientId;
> }
> *BusinessObject is just a generic Object that maintains a reference to the Assertion List from where it came (Ref. to the container object, Collection).
> Action(s):
> -------------
> 1. initialize the object with a Parameter and Value (Hard code to test) -- Set
> 2. Execute against a Rule:
> When
>    config: BooleanConfiguration(value==true)
> Then
>   //Do something
> end
> EXECUTION NOTES:
> -------------------------------
> 1. I asserted this object and the rule was not executing as I expected.
> 2. I put a break point in the object, and found that it set it correctly but 
> whenenver the rule engine called the get method the vaue of the object was null.
> 3. I traced this the place where it creates shadows in Rete.java.
> I had observed a similar behaviour in version 3.1 or 3.6 (if there was a 3.6).
> it was more prolific then.
> 4. I made the class 'final' (This prevents a shadow from being created), and voila
> my rule worked as expected. 
> Note: None of the other objects needed a final, but had comeplex associations.
> But this particular object does not run, unless declared 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 lists.jboss.org  Thu Aug  2 01:41:50 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 01:41:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32023670.1186033310135.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-783?page=comments#action_12370815 ] 
            
Ron Sigal commented on JBREM-783:
---------------------------------

Changes have been made to MicroRemoteClientInvoker.establishLease(), terminateLease(), and org.jboss.remoting.LeasePinger.  

establishLease() has been changed so that the first org.jboss.remoting.Client to call establishLease() and see LeasePinger == null becomes responsible for creating LeasePinger.  All other Client's wait until the first Client informs them that LeasePinger has been created.  Once the job of creating the LeasePinger has been assigned, the Client with that responsibility can exit the synchronization block before doing any network i/o.

The changes to terminateLease() are based on changes to LeasePinger, where the network i/o in removeClient() has been moved to a new method, disconnectClient().  terminateLease() calls removeClient() inside the synchronization block and disconnectClient() outside the synchronization block.

Unit test:  org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Thu Aug  2 01:49:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 01:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1023)
 setStringProperty call
 after a clearProperties call will make getJMSDestination to be null
Message-ID: <27508466.1186033789339.JavaMail.jira@cloud.prod.atl2.jboss.com>

setStringProperty call after a clearProperties call will make getJMSDestination to be null
------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1023
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1023
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR1
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 01:53:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 01:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1023)
 clearProperties call will make getJMSDestination to be null
In-Reply-To: <27508466.1186033789339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11603799.1186034029333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1023?page=all ]

Clebert Suconic updated JBMESSAGING-1023:
-----------------------------------------

    Summary: clearProperties call will make getJMSDestination to be null  (was: setStringProperty call after a clearProperties call will make getJMSDestination to be null)

> clearProperties call will make getJMSDestination to be null
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1023
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1023
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:17:53 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:17:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1035)
	StateTransfer200AopTest fails
In-Reply-To: <27241307.1177419690186.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13962128.1186035473850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1035?page=all ]

Jason T. Greene resolved JBCACHE-1035.
--------------------------------------

    Resolution: Done

> StateTransfer200AopTest fails
> -----------------------------
>
>                 Key: JBCACHE-1035
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1035
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Jason T. Greene
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:19:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1125) pojo demo GUI
 doesn't appear (2.0 CR3)
In-Reply-To: <7770922.1183992218930.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16226352.1186035589390.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1125?page=all ]

Jason T. Greene resolved JBCACHE-1125.
--------------------------------------

    Resolution: Done

> pojo demo GUI doesn't appear (2.0 CR3)
> --------------------------------------
>
>                 Key: JBCACHE-1125
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1125
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.CR3
>         Environment: linux, jdk1.5.0_11
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> ./build.sh run.demo.pojocache" doesn't produce a gui window but just hangs after the line:
>      [java] start(): creating the GUI

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:21:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1126) distribution
 example cannot complete (2.0 CR3)
In-Reply-To: <10827053.1183997911833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33481087.1186035709412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1126?page=all ]

Jason T. Greene resolved JBCACHE-1126.
--------------------------------------

    Resolution: Done

> distribution example cannot complete (2.0 CR3)
> ----------------------------------------------
>
>                 Key: JBCACHE-1126
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1126
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.CR3
>         Environment: linux, jdk1.5.0_11
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> All examples fail - some can't compile, some at runtime. These that compile are running and seem to do something (at least eat some CPU cycles) but don't complete within few minutes and through exceptions so I consider them failing. Anything I'm doing wrong? btw I run with ant.
> One problem with a known reason: on loadtime example path is specified with ";" between file names and not ":". To be portable to windows and unix ant path or location element has to 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 lists.jboss.org  Thu Aug  2 02:21:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-846) PojoCache 2.0 key
	features
In-Reply-To: <32822703.1163506601857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9378704.1186035709580.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-846?page=all ]

Jason T. Greene resolved JBCACHE-846.
-------------------------------------

    Resolution: Done

> PojoCache 2.0 key features
> --------------------------
>
>                 Key: JBCACHE-846
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-846
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>
> Manik, FYI, followings are the key features for PojoCache 2.0. When do the announcement later, please include them in. Thanks! -Ben
> Key PojoCache 2.0 features:
> 1. Supports replicated POJO field as Enum class (JBCACHE-619)
> 2. Option to replicate POJO final field (JBCACHE-839)
> 3. Support JDK5.0 only
> 4. PojoCache provides MBean interface (JBCACHE-783)
> 5. Uses a pojocache-aop.xml for configuration (JBCACHE-780)
> 6. Handle complete rollback of POJO field operation under transaction if needed (JBCACHE-723)
> 7. PojoCache to throw PojoCacheException only runtime exception (JBCACHE-700)
> 8. Interceptor based architecture to allow easy customization (JBCACHE-588)
> 9. PojoCache now uses Cache as a delegate (JBCACHE-673)
> 10. PojoCache event listener (JBCACHE-85)
> 11. During passivation, PojoCache now lazily loads the individual POJO.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:34:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 02:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23141024.1186036489324.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-783?page=comments#action_12370820 ] 
            
Ron Sigal commented on JBREM-783:
---------------------------------

The changes have been applied to the remoting_2_2_0_GA branch.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Thu Aug  2 02:45:50 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 02:45:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8468083.1186037150042.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-783?page=comments#action_12370823 ] 
            
Ron Sigal commented on JBREM-783:
---------------------------------

The changes have been applied to the remoting_2_x branch.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Thu Aug  2 02:54:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1088) problem with
 tests in examples/PojoCache
In-Reply-To: <25815662.1180710008483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5908070.1186037689483.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1088?page=all ]

Jason T. Greene resolved JBCACHE-1088.
--------------------------------------

    Resolution: Done

> problem with tests in examples/PojoCache
> ----------------------------------------
>
>                 Key: JBCACHE-1088
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1088
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 2.0.0.CR2
>            Reporter: Prabhat Jha
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> Running tests in examples/PojoCache has some failures and errors.
> JBossCache-all-2.0.0.CR2/examples/PojoCache/loadtime - Error
>         java.lang.Exception: Don't know how to marshall object of type class examples.Student
> JBossCache-all-2.0.0.CR2/examples/PojoCache/non-annotated - Error
>        javassist.NotFoundException: org.jboss.cache.pojo.observable.SubjectImpl
> JBossCache-all-2.0.0.CR2/examples/PojoCache/passivation - Error
>     ./build.sh compile fails with
>     test.examples.StudentMaintTest.MyCacheListener is not abstract and does not override abstract method nodePassivated(org.jboss.cache.Fqn,boolean,java.util.Map<java.lang.Object,java.lang.Object>) in
>    org.jboss.cache.CacheListener
>     [javac] public class MyCacheListener implements CacheListener
>     [javac] ^
>     [javac] 1 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 lists.jboss.org  Thu Aug  2 02:56:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-172) Strange
 performance problem with LRU
Message-ID: <2766604.1186037809648.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-172?page=all ]

Jason T. Greene updated JBCACHE-172:
------------------------------------

    Fix Version/s: 2.1.0.GA
                       (was: 2.0.0.GA)

> Strange performance problem with LRU
> ------------------------------------
>
>                 Key: JBCACHE-172
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-172
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.2
>         Environment: Windows XP
> Eclipse 3.1
> JDK50
>            Reporter: Peter Bridge
>         Assigned To: Jason T. Greene
>            Priority: Minor
>             Fix For: 2.1.0.GA
>
>         Attachments: CachePerformanceTest.java, treecacheconfig.xml
>
>
> There seems to be a performance issue when using the LRU option.  With the attaches test, the 100,000 item Get takes 1200ms with LRU and 800ms without any config loaded.  I also noticed the put is slower.  
> get, put, remove
> 2704	1187	625     configured
> 2204	812	625     not configured
> For comparison I used a LinkedHashMap configured as LRU and get these figures:
> 1370	184	172
> Is this an issue with my configuration? Or a problem with how I'm using the cache?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 02:58:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 2 Aug 2007 02:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-472) Release JBoss
	Cache 2.0
Message-ID: <30786047.1186037929443.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-472?page=all ]

Jason T. Greene reassigned JBCACHE-472:
---------------------------------------

    Assignee: Ryan Campbell  (was: Manik Surtani)

JBossCache_2_0_0_GA is taggged and ready for QA

Thanks!

> Release JBoss Cache 2.0
> -----------------------
>
>                 Key: JBCACHE-472
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-472
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Ryan Campbell
>             Fix For: 2.0.0.GA
>
>
> Add all release tasks here (docos, tutorials, dr through to rc, 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 lists.jboss.org  Thu Aug  2 02:58:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 02:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10310885.1186037929572.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-782?page=comments#action_12370825 ] 
            
Ron Sigal commented on JBREM-782:
---------------------------------

The solution is just to break up the synchronization blocks in getCallbackHandler() into two blocks, without the call to the ServerIinvokerCallbackHandler constructor.

The fix has been applied to the remoting_2_2_0_GA branch.

There is no specific unit test.

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 03:12:56 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 03:12:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently changes listenerId member variable
Message-ID: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>

BisocketClientInvoker.transport() inadvertently changes listenerId member variable
----------------------------------------------------------------------------------

                 Key: JBREM-785
                 URL: http://jira.jboss.com/jira/browse/JBREM-785
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.1.GA, 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on 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 lists.jboss.org  Thu Aug  2 03:40:49 2007
From: jira-events at lists.jboss.org (Peter Bomben (JIRA))
Date: Thu, 2 Aug 2007 03:40:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
Message-ID: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL-Editor: "Add" button does not work
--------------------------------------

                 Key: JBRULES-1054
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 4.0.1
         Environment: Eclipse-IDE: DSL-Editor
            Reporter: Peter Bomben
         Assigned To: Mark Proctor


Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Thu Aug  2 03:50:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 03:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26536235.1186041049318.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-785?page=all ]

Ron Sigal updated JBREM-785:
----------------------------

        Summary: BisocketClientInvoker.transport() inadvertently uses listenerId member variable  (was: BisocketClientInvoker.transport() inadvertently changes listenerId member variable)
    Description: 
org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.

The fix is just to use a stack variable instead of the member variable.

  was:org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.


> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 03:54:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 2 Aug 2007 03:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-785)
 BisocketClientInvoker.transport() inadvertently uses listenerId member
 variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17130811.1186041289329.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-785?page=comments#action_12370835 ] 
            
Ron Sigal commented on JBREM-785:
---------------------------------

The fix has been applied to the remoting_2_2_0_GA branch.

Unit test:  org.jboss.test.remoting.transport.bisocket.listenerID.ListenerIDonStackTestCase.

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 04:22:51 2007
From: jira-events at lists.jboss.org (Takayuki Kaneko (JIRA))
Date: Thu, 2 Aug 2007 04:22:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4590) Add new parameter of
 jnp for connecting each time.
Message-ID: <28892709.1186042971102.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add new parameter of jnp for connecting each time.
--------------------------------------------------

                 Key: JBAS-4590
                 URL: http://jira.jboss.com/jira/browse/JBAS-4590
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Naming
            Reporter: Takayuki Kaneko
         Assigned To: Scott M Stark


I want to add a new parameter on org.jnp.interfaces.NamingContext for connecting 1099 port each time.
Our system needs to connect JNDI each time because there is a load balancer between EJB clients and JBoss servers.

Of course I know the caching server stubs is needed to improve the performance. Our issue might be minority.
So I made a patch that wouldn't change the default behavior about caching.

Could you consider the possibilities of applying this patch? We want to use JBoss Application Server on our system.
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 lists.jboss.org  Thu Aug  2 04:33:49 2007
From: jira-events at lists.jboss.org (Takayuki Kaneko (JIRA))
Date: Thu, 2 Aug 2007 04:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4590) Add new parameter of
 jnp for connecting each time.
In-Reply-To: <28892709.1186042971102.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6736813.1186043629366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4590?page=all ]

Takayuki Kaneko updated JBAS-4590:
----------------------------------

    Attachment: patch.txt

I changed some methods from static to instance because it is difficult to expand the new feature.
I didn't move these method to right position on source code because it would be difficult to pick out diffs.

> Add new parameter of jnp for connecting each time.
> --------------------------------------------------
>
>                 Key: JBAS-4590
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4590
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>            Reporter: Takayuki Kaneko
>         Assigned To: Scott M Stark
>         Attachments: patch.txt
>
>
> I want to add a new parameter on org.jnp.interfaces.NamingContext for connecting 1099 port each time.
> Our system needs to connect JNDI each time because there is a load balancer between EJB clients and JBoss servers.
> Of course I know the caching server stubs is needed to improve the performance. Our issue might be minority.
> So I made a patch that wouldn't change the default behavior about caching.
> Could you consider the possibilities of applying this patch? We want to use JBoss Application Server on our system.
> 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 lists.jboss.org  Thu Aug  2 06:26:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 2 Aug 2007 06:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1030) session closed before
 jbpmContext close
In-Reply-To: <30881023.1186024253983.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23884588.1186050409395.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1030?page=all ]

Ronald van Kuijk closed JBPM-1030.
----------------------------------

    Resolution: Incomplete Description

you close the context first and then still try to set a taskinstance etc.... looks like a wrong example. So I'm closing this. Reopen with more proof if you think I'm wrong.

> session closed before jbpmContext close
> ---------------------------------------
>
>                 Key: JBPM-1030
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1030
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: win2000,tomcat,jbpm3.2,eclipse
>            Reporter: zhang baoquan
>         Assigned To: Tom Baeyens
>
> Session hsession = jbpmContext.getSession();
> try {            
>             hsession.save(businessReport);
>             ProcessDefinition pd = jbpmContext.getGraphSession().findLatestProcessDefinition("RNDFProcess");
>             ProcessInstance pi = pd.createProcessInstance();
>             //pi.getContextInstance().setVariable("username", from_username);
>             TaskInstance ti = pi.getTaskMgmtInstance().createStartTaskInstance();
>             jbpmContext.close();//here is exception
>             ti.setVariable("report_id", businessReport.getReportId());
>             ti.end();
> } catch (Exception e) {
> 	System.out.println("Unknown error in the SaveGo().");
> 	e.printStackTrace();
> 	jbpmContext.setRollbackOnly();
> }finally{
>             jbpmContext.close();
> }
> exception:
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
> 09:36:53,328 [http8001-Processor22] DEBUG JbpmContext : creating org.jbpm.JbpmContext at 1ddf47e
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceServiceFactory : creating persistence service
> 09:36:53,328 [http8001-Processor22] DEBUG DbPersistenceService : creating hibernate session
> 09:36:53,343 [http8001-Processor22] DEBUG DbPersistenceService : beginning hibernate transaction
> 09:36:53,359 [http8001-Processor22] DEBUG GraphElement : event 'process-start' on 'ProcessDefinition(RNDFProcess)' for 'Token(/)'
> 09:36:53,359 [http8001-Processor22] WARN  StatefulPersistenceContext : Narrowing proxy to class org.jbpm.graph.node.StartState - this operation breaks ==
> 09:36:53,375 [http8001-Processor22] DEBUG TaskController : creating task instance variable 'report_id' from process variable 'report_id', value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG VariableContainer : create variable 'report_id' in 'TaskInstance[appendForm]' with value 'null'
> 09:36:53,375 [http8001-Processor22] DEBUG GraphElement : event 'task-create' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG GraphElement : event 'task-assign' on 'Task(appendForm)' for 'Token(/)'
> 09:36:56,203 [http8001-Processor22] DEBUG JbpmContext : closing JbpmContext
> 09:36:56,203 [http8001-Processor22] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 9d478b
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : committing hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate commit failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:139)
> 	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:115)
> 	at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:253)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:211)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] DEBUG DbPersistenceService : rolling back hibernate transaction
> 09:36:56,203 [http8001-Processor22] ERROR DbPersistenceService : hibernate rollback failed
> org.hibernate.SessionException: Session is closed
> 	at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:116)
> 	at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:183)
> 	at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)
> 	at org.jbpm.persistence.db.DbPersistenceService.rollback(DbPersistenceService.java:297)
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:213)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	at java.lang.Thread.run(Thread.java:595)
> 09:36:56,203 [http8001-Processor22] WARN  DbPersistenceService : hibernate session was already closed
> org.jbpm.persistence.JbpmPersistenceException: hibernate commit failed
> 	at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:216)
> 	at org.jbpm.svc.Services.close(Services.java:222)
> 	at org.jbpm.JbpmContext.close(JbpmContext.java:139)
> 	at buesiness.BusinessEngine.SaveGo(BusinessEngine.java:113)
> 	at buesiness.BusinessEngine.exectue(BusinessEngine.java:62)
> 	at org.apache.jsp.order_005fexec_jsp._jspService(order_005fexec_jsp.java:99)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
> 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:563)
> 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972)
> 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:209)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:670)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:517)
> 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
> 	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 lists.jboss.org  Thu Aug  2 08:07:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:07:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <7418970.1186056469335.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers moved JBIDE-640 to GPD-126:
-------------------------------------

              Project: JBoss jBPM GPD  (was: JBoss Tools)
                  Key: GPD-126  (was: JBIDE-640)
          Component/s:     (was: Seam)
    Affects Version/s: jBPM JPDL Designer 3.1.0.beta2
                           (was: 2.0.0.20070731)

> CLONE -New Page Flow broken - exception
> ---------------------------------------
>
>                 Key: GPD-126
>                 URL: http://jira.jboss.com/jira/browse/GPD-126
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Blocker
>
> Ctrl+N, select Page Flow and Next or Finish gives multiple errors and the dialog is just stuck:
> java.lang.IllegalArgumentException: Path must include project and resource name: /
> at org.eclipse.core.runtime.Assert.isLegal(Assert.java:62)
> at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1625)
> at org.eclipse.core.internal.resources.Container.getFolder(Container.java:137)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getProcessFolder(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.performFinish(Unknown Source)
> at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:742
> java.lang.NullPointerException
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getRootForEmbeddingProject(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.initContainerName(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.init(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.addPages(Unknown Source)
> at org.eclipse.jface.wizard.WizardSelectionPage.getNextPage(WizardSelectionPage.java:113)
> java.lang.IllegalArgumentException: Argument cannot be null
> 	at org.eclipse.swt.SWT.error(SWT.java:3547)
> 	at org.eclipse.swt.SWT.error(SWT.java:3481)
> 	at org.eclipse.swt.SWT.error(SWT.java:3452)
> 	at org.eclipse.swt.widgets.Widget.error(Widget.java:438)
> 	at org.eclipse.swt.widgets.Text.setText(Text.java:1870)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createContainerField(Unknown Source)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createControl(Unknown Source)
> 	at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170)
> 	at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:669)
> 	at org.eclipse.jface.wizard.WizardDialog.setWizard(WizardDialog.java:1083)
> 	at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1142)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:09:56 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <1228625.1186056596775.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers moved JBIDE-641 to GPD-127:
-------------------------------------

              Project: JBoss jBPM GPD  (was: JBoss Tools)
                  Key: GPD-127  (was: JBIDE-641)
          Component/s:     (was: jbpm)
    Affects Version/s: jBPM JPDL Designer 3.1.0.beta2
                           (was: 2.0.0.20070731)

> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:11:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:11:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <13225300.1186056709392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers updated GPD-127:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 08:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <33315762.1186057009343.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers updated GPD-126:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> CLONE -New Page Flow broken - exception
> ---------------------------------------
>
>                 Key: GPD-126
>                 URL: http://jira.jboss.com/jira/browse/GPD-126
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Blocker
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> Ctrl+N, select Page Flow and Next or Finish gives multiple errors and the dialog is just stuck:
> java.lang.IllegalArgumentException: Path must include project and resource name: /
> at org.eclipse.core.runtime.Assert.isLegal(Assert.java:62)
> at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1625)
> at org.eclipse.core.internal.resources.Container.getFolder(Container.java:137)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getProcessFolder(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.performFinish(Unknown Source)
> at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:742
> java.lang.NullPointerException
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getRootForEmbeddingProject(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.initContainerName(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.init(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.addPages(Unknown Source)
> at org.eclipse.jface.wizard.WizardSelectionPage.getNextPage(WizardSelectionPage.java:113)
> java.lang.IllegalArgumentException: Argument cannot be null
> 	at org.eclipse.swt.SWT.error(SWT.java:3547)
> 	at org.eclipse.swt.SWT.error(SWT.java:3481)
> 	at org.eclipse.swt.SWT.error(SWT.java:3452)
> 	at org.eclipse.swt.widgets.Widget.error(Widget.java:438)
> 	at org.eclipse.swt.widgets.Text.setText(Text.java:1870)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createContainerField(Unknown Source)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createControl(Unknown Source)
> 	at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170)
> 	at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:669)
> 	at org.eclipse.jface.wizard.WizardDialog.setWizard(WizardDialog.java:1083)
> 	at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1142)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:36:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 2 Aug 2007 08:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1023) Default local
 interface is not picked up if class is woven with JBoss AOP
In-Reply-To: <27657471.1185982189290.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3978297.1186058209581.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1023?page=all ]

Kabir Khan closed EJBTHREE-1023.
--------------------------------

    Resolution: Done

> Default local interface is not picked up if class is woven with JBoss AOP
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1023
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1023
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1, AS 4.2.1.GA
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD
>
>
> If weaving the following bean
> public interface SessionLocal{
>    void method();
> }
> @Stateful
> public bean Session implements Session{
>    void method(){}
> }
> following weaving it implements Session AND org.jboss.aop.Advised, i.e. > 1 interface so the local proxy does not get bound into JNDI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 08:57:49 2007
From: jira-events at lists.jboss.org (Kristof Devos (JIRA))
Date: Thu, 2 Aug 2007 08:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1031) Use multiple
	VariableResolvers?
Message-ID: <22519919.1186059469622.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use multiple VariableResolvers?
-------------------------------

                 Key: JBPM-1031
                 URL: http://jira.jboss.com/jira/browse/JBPM-1031
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
    Affects Versions: jBPM 3.1.3
            Reporter: Kristof Devos
         Assigned To: Tom Baeyens
            Priority: Minor


JbpmExpressionValidator uses a static VariableResolver (in case of seam usage it always SeamVariableResolver), in this case it is no longer possible to put variables in the JBPM context instance to resolve in expressions, would it be nice to have multiple  expressionvalidator possible in sorted order to make sure seam context and jbpm context can be used in any 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 lists.jboss.org  Thu Aug  2 09:19:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 2 Aug 2007 09:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
Message-ID: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>

@Local and @Remote on a bean class must have values
---------------------------------------------------

                 Key: EJBTHREE-1025
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.0 GA
            Reporter: Carlo de Wolf
             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD


The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 10:28:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 2 Aug 2007 10:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-450) AOP/MC Proxies do
 not include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23772375.1186064929481.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-450?page=all ]

Kabir Khan updated JBAOP-450:
-----------------------------

    Summary: AOP/MC Proxies do not include original Annotation and Signature attributes  (was: AOP/MC Proxies do not include original annotations)

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.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 lists.jboss.org  Thu Aug  2 11:09:49 2007
From: jira-events at lists.jboss.org (Karsten Dello (JIRA))
Date: Thu, 2 Aug 2007 11:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1032) task-assign-events
 are sometimes fired when group assignment is performed
Message-ID: <3085964.1186067389360.JavaMail.jira@cloud.prod.atl2.jboss.com>

task-assign-events are sometimes fired when group assignment is performed
-------------------------------------------------------------------------

                 Key: JBPM-1032
                 URL: http://jira.jboss.com/jira/browse/JBPM-1032
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: Karsten Dello
         Assigned To: Tom Baeyens


A "task-assingn"-event is sometimes fired, if only group assignment (setting pooledActors) is performed. This always happens when a swimlane is in use which specifies pooled-actors (junit test 1). 

On the other hand, when the  pooled-actors are expressed via an assignment-element as an child element of a task (junit test 2), the event is not fired.

>From my point of view the engine should either:
a) not fire an task-assign-event in case of group assignments at all
b) fire it consequently at all group assignments events
c) fire a different event

Ronald suggested in the forum thread (link above) to introduce a seperate event "task-group-assign" in case a task gets assigned to a group. In my opinion this would be the best solution to this problem.


	public void testTaskAssignIsFiredWithSwimlaneGroupAssignment() {


		ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
				"<process-definition name=\"someprocessxyz\">" +
				
				"  <event type=\"task-assign\">" +
				"    <script>System.out.println(\"task-assign-event fired!\");" +
				"			executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+
				"  </event>"+

				"  <start-state>" +
				"    <transition to='a' />" +
				"  </start-state>" +
				
				"  <swimlane name='swimlane22'>"+
				"    <assignment pooled-actors='jan,nina'/>"+
				"  </swimlane>"+

				"  <task-node name='a'>" +
				"    <task name='sometask' swimlane='swimlane22'/>" +
				"    <transition to='end'/>"+
				"  </task-node>"+
				
				"  <end-state name='end' />" +
				
				"</process-definition>"
		);
		ProcessInstance processInstance = new ProcessInstance(processDefinition);
		Token token = processInstance.getRootToken();
		

		processInstance.signal();
		Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired");
		assertEquals(Boolean.TRUE, o);

		
	}

	public void testTaskAssignIsNOTFiredWithSwimlaneGroupAssignment() {


		ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
				"<process-definition name=\"someprocessxyz\">" +
				
				"  <event type=\"task-assign\">" +
				"    <script>System.out.println(\"task-assign-event fired!\")"+
				"			executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+
				"  </event>"+

				"  <start-state>" +
				"    <transition to='a' />" +
				"  </start-state>" +
				

				"  <task-node name='a'>" +
				"    <task name='sometask'>" +
				"    	<assignment pooled-actors='jan,nina'/>"+
				"    </task>"+
				"    <transition to='end'/>"+
				"  </task-node>"+
				
				"  <end-state name='end' />" +
				
				"</process-definition>"
		);
		ProcessInstance processInstance = new ProcessInstance(processDefinition);
		Token token = processInstance.getRootToken();

		processInstance.signal();
		
		Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired");
		assertEquals(Boolean.TRUE, o);
	}




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:28:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 11:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <3513653.1186068529246.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers resolved GPD-126.
---------------------------

    Resolution: Done

The problem should be fixed now.

> CLONE -New Page Flow broken - exception
> ---------------------------------------
>
>                 Key: GPD-126
>                 URL: http://jira.jboss.com/jira/browse/GPD-126
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Blocker
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> Ctrl+N, select Page Flow and Next or Finish gives multiple errors and the dialog is just stuck:
> java.lang.IllegalArgumentException: Path must include project and resource name: /
> at org.eclipse.core.runtime.Assert.isLegal(Assert.java:62)
> at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1625)
> at org.eclipse.core.internal.resources.Container.getFolder(Container.java:137)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getProcessFolder(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.performFinish(Unknown Source)
> at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:742
> java.lang.NullPointerException
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getRootForEmbeddingProject(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.initContainerName(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.init(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.addPages(Unknown Source)
> at org.eclipse.jface.wizard.WizardSelectionPage.getNextPage(WizardSelectionPage.java:113)
> java.lang.IllegalArgumentException: Argument cannot be null
> 	at org.eclipse.swt.SWT.error(SWT.java:3547)
> 	at org.eclipse.swt.SWT.error(SWT.java:3481)
> 	at org.eclipse.swt.SWT.error(SWT.java:3452)
> 	at org.eclipse.swt.widgets.Widget.error(Widget.java:438)
> 	at org.eclipse.swt.widgets.Text.setText(Text.java:1870)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createContainerField(Unknown Source)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createControl(Unknown Source)
> 	at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170)
> 	at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:669)
> 	at org.eclipse.jface.wizard.WizardDialog.setWizard(WizardDialog.java:1083)
> 	at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1142)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:31:40 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Aug 2007 11:31:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-129) Logical addresses
Message-ID: <392589.1186068700914.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-129?page=comments#action_12370883 ] 
            
Bela Ban commented on JGRP-129:
-------------------------------

I'm not sure I want to introduce logical addresses. This is regarding
JGRP-129 (logical addresses)  and JGRP-130 (problems with reincarnation).

JGRP-130 is about a member that leaves and rejoins *under the same IP address and port (using bind/start_port)* before failure detection kicks it out. I implemented a fix for this, which won't allow a member into the group that's already in the group. In the above case, with A and B, B would have to wait until the cluster is {A} before it can rejoin.

JGRP-129 is about providing a logical address (possibly host + system time in ms (plus 1 for same system times) for a member, which can be mapped to a physical host/port combo. It would add 4 bytes/address, and I don't see the benefits of this.

The original motivation was that when a member gets shunned, it rejoins under a new identity. Sacha didn't like this and therefore added 'logical addresses' in JBoss, which creates a logical address for a member. So when that member is shunned and rejoins under a *new* JGroups address, it would still keep the *old* JBoss logical address.

I tend to leave it this way, as I don't want to add something which
- adds clutter (Host:26634425614 looks less readable than Host:4536)
- adds 4 bytes / IpAddress
- has some additional lookup in the transport to find the real physical address to which the logical address maps
- needs some ARP-like traffic for establishing local tables which map logical to physical addresses

What do people think ?

> Logical addresses
> -----------------
>
>                 Key: JGRP-129
>                 URL: http://jira.jboss.com/jira/browse/JGRP-129
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough:
> - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper
> - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC
> - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on
> - Network Address Translation: the sender's address might get changed by the NAT
> DESIGN: 
> - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called.
> - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true").
> - The logical addresses must be picked such that they cannot be reused after disconnect()/close().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:32:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Aug 2007 11:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-130) Problems with
	reincarnation
Message-ID: <17351721.1186068769738.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12370885 ] 
            
Bela Ban commented on JGRP-130:
-------------------------------

Implementing GMS.reject_join_from_existing_member pretty much fixed this issue. I don't see the need for logical addresses any more. I added a comment to http://jira.jboss.com/jira/browse/JGRP-129. What do people think, is there still a compelling reason we need logical addresses ?

> Problems with reincarnation
> ---------------------------
>
>                 Key: JGRP-130
>                 URL: http://jira.jboss.com/jira/browse/JGRP-130
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: tcp.xml
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:57:49 2007
From: jira-events at lists.jboss.org (Michael Wiedmer (JIRA))
Date: Thu, 2 Aug 2007 11:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
Message-ID: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>

Regex-Special characters can not be used in DSLs.
-------------------------------------------------

                 Key: JBRULES-1055
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Java 5
            Reporter: Michael Wiedmer
         Assigned To: Mark Proctor


Up until Drools 3.0.6 one could write DSLs to allow expressions such as

EXAMPLE IS IN [ "one" "two"]

This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.


Here is a (not) working example, using the default sample project:

8<---- regexError.drl -----
package some.test

import com.sample.*;

expander regexError.dsl

rule "Test"
	when
		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
	then 
		LOG "Square Brackets will not work."
end
8<---- regexError.dsl -----
[consequence][]LOG {msg}=System.out.println({msg});
[condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
8<---- DroolsTest.javal -----
package com.sample;

import java.io.InputStreamReader;
import java.io.Reader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class DroolsTest {

    public static final void main(String[] args) {
        try {

            // load up the rulebase
            RuleBase ruleBase = readRule();
            WorkingMemory workingMemory = ruleBase.newStatefulSession();

            // go !
            Message message = new Message();
            message.setMessage("Hello World");
            message.setStatus(Message.HELLO);
            workingMemory.insert(message);
            workingMemory.fireAllRules();

        } catch (Throwable t) {
            t.printStackTrace();
        }
    }

    private static RuleBase readRule() throws Exception {
        Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));

        Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
        PackageBuilder builder = new PackageBuilder();

        builder.addPackageFromDrl(source, dsl);

        Package pkg = builder.getPackage();

        RuleBase ruleBase = RuleBaseFactory.newRuleBase();
        ruleBase.addPackage(pkg);
        return ruleBase;
    }
}


If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:

org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
	at org.drools.rule.Package.checkValidity(Package.java:408)
	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
	at com.sample.DroolsTest.main(DroolsTest.java:18)

It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 11:59:49 2007
From: jira-events at lists.jboss.org (Michael Wiedmer (JIRA))
Date: Thu, 2 Aug 2007 11:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24072520.1186070389682.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1055?page=all ]

Michael Wiedmer updated JBRULES-1055:
-------------------------------------

    Workaround Description: Users could replace the square brackets with other characters, e.g. the angle brackets. I do not want to be the one who has to bring it to the users to use a new syntax, though.  (was: Users could replace the square brackets with other characters, e.g. the angle brackets.)

> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Mark Proctor
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 12:17:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 2 Aug 2007 12:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <29046442.1186071469231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers resolved GPD-127.
---------------------------

    Resolution: Done

> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 13:07:03 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 2 Aug 2007 13:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-450) AOP/MC Proxies do
 not include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29439629.1186074423449.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-450?page=comments#action_12370908 ] 
            
Kabir Khan commented on JBAOP-450:
----------------------------------

Awaiting reply from Chiba about possible problemin javassist

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.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 lists.jboss.org  Thu Aug  2 14:02:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 14:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1023)
 clearProperties call will make getJMSDestination to be null
In-Reply-To: <27508466.1186033789339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18642412.1186077769432.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1023?page=all ]

Clebert Suconic closed JBMESSAGING-1023.
----------------------------------------

    Resolution: Done

> clearProperties call will make getJMSDestination to be null
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1023
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1023
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 16:46:54 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Thu, 2 Aug 2007 16:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-274) wsdl service
 generator: eliminate reliance on transitive imports
Message-ID: <19592587.1186087614143.JavaMail.jira@cloud.prod.atl2.jboss.com>

wsdl service generator: eliminate reliance on transitive imports
----------------------------------------------------------------

                 Key: BPEL-274
                 URL: http://jira.jboss.com/jira/browse/BPEL-274
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Engine
    Affects Versions: jBPM BPEL 1.1 beta 3
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1 GA


PROBLEM Consider the following network of WSDL documents.

<definitions name="d1" targetNamespace="ns1">
 <import namespace="ns2" location="d2" />
 <binding name="b" type="ns3:pt" />
</definitions>

<definitions name="d2" targetNamespace="ns2">
 <import namespace="ns3" location="d3" />
 <partnerLinkType name="plt">
  <role portType="ns3:pt" />
 </partnerLinkType>
</definitions>

<definitions name="d3" targetNamespace="ns3">
 <portType name="pt" />
</definitions>

ns2:plt is able to resolve the reference tons3:pt, but ns1:b is not. The import element in d1 is not scanned because the binding refers to a port type in namespace ns3 and the import namespace URI is ns2. 

jBPM BPEL is able to resolve such transitive references, but products like the Eclipse BPEL designer and JBossWS are not. 

PROPOSAL While generating d1, create a direct import for d3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 16:54:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Thu, 2 Aug 2007 16:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5555246.1186088089385.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12370936 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

Koen,

I started working with the updated code and am having issues with the priorities. i had defined all of the priorities within my product to be the same - for example, all of my nodes had a priority of -99 as i didnt expect to have to break ties within the product. I'd prefer to allow two nodes to have the same priority. otherwise i have to generate a different priority for each of my nodes - its possible but more work to maintain...

otherwise it is working well so far. i will do more testing over the next week.


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 16:58:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 2 Aug 2007 16:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-998) enable removal of
	EJB3 Timers
In-Reply-To: <27446369.1183052877624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27068798.1186088329372.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-998?page=all ]

William DeCoste closed EJBTHREE-998.
------------------------------------

    Resolution: Cannot Reproduce Bug

> enable removal of EJB3 Timers
> -----------------------------
>
>                 Key: EJBTHREE-998
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-998
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: AS 4.2.0 GA
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 17:08:59 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 2 Aug 2007 17:08:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
Message-ID: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>

Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
---------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1056
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows
            Reporter: Ming Jin
         Assigned To: Mark Proctor


I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
 
Added 20 packages to rulebase in 0:00:0.15
Added 20 packages to rulebase in 0:00:0.21
Added 20 packages to rulebase in 0:00:0.21
Added 20 packages to rulebase in 0:00:0.301
Added 20 packages to rulebase in 0:00:0.18
Added 20 packages to rulebase 5 times in 0:00:1.051
 
Added 50 packages to rulebase in 0:00:0.17
Added 50 packages to rulebase in 0:00:1.422
Added 50 packages to rulebase in 0:00:1.252
Added 50 packages to rulebase in 0:00:1.322
Added 50 packages to rulebase in 0:00:1.331
Added 50 packages to rulebase 5 times in 0:00:5.497
 
Added 100 packages to rulebase in 0:00:0.19
Added 100 packages to rulebase in 0:00:5.278
Added 100 packages to rulebase in 0:00:5.297
Added 100 packages to rulebase in 0:00:5.228
Added 100 packages to rulebase in 0:00:5.327
Added 100 packages to rulebase 5 times in 0:00:21.32
 
Added 200 packages to rulebase in 0:00:0.22
Added 200 packages to rulebase in 0:00:21.691
Added 200 packages to rulebase in 0:00:21.481
Added 200 packages to rulebase in 0:00:21.642
Added 200 packages to rulebase in 0:00:21.341
Added 200 packages to rulebase 5 times in 0:01:26.385
 
As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.

The following test program would demonstrate the problem:
import java.util.List;
import java.util.ArrayList;
import java.util.Random;
import java.io.StringReader;
import java.io.IOException;

import org.drools.rule.Package;
import org.drools.compiler.PackageBuilder;
import org.drools.compiler.DroolsParserException;
import org.drools.RuleBase;
import org.drools.RuleBaseFactory;

/**
 * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
 * Settings | File Templates.
 */
public class TestDrools {
  private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
  private static final String DRL_TEMPLATE  =
          "package testpackage\n" +
          "import test.TestObject\n"+
          "rule \"testrule_$1\"\n" +
          "  when\n" +
          "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
          "  then\n" +
          "    h.setResult(\"$4\");\n" +
          "end";
  private int count;

  public TestDrools(int count) {
    this.count  = count;
  }

  public void run() throws Exception {
    List<String>  drls  = generateDrls();
    List<Package> pkgs  = generatePackages(drls);

    for (int i = 0; i < 3; i++) {
      addPackages(pkgs, i+1);
    }
  }

  private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
    long     time  = System.currentTimeMillis();
    RuleBase rb  = RuleBaseFactory.newRuleBase();
    for (Package pkg : pkgs)
      rb.addPackage(pkg);
    System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
                       (System.currentTimeMillis()-time)/1000.0+" seconds");
    return rb;
  }

  private List<String> generateDrls() {
    List<String>  list  = new ArrayList<String>(count);
    for (int i = 0; i < count; i++) {
      list.add(getDrl(i));
    }
    return list;
  }

  private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
    List<Package> list  = new ArrayList<Package>(drls.size());
    for (String drl : drls) {
      PackageBuilder  builder = new PackageBuilder();
      builder.addPackageFromDrl(new StringReader(drl));
      list.add(builder.getPackage());
    }
    return list;
  }

  private String getDrl(int seed) {
    String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));

    drl = drl.replace("$2", getRandomString());
    drl = drl.replace("$3", getRandomString());
    return drl.replace("$4", getRandomString());
  }

  private Random  rand  = new Random();

  private String getRandomString() {
    StringBuilder sb  = new StringBuilder();

    for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
      sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
    return sb.toString();
  }

  public static void main(String[] argv) {
    if (argv.length > 0) {
      try {
        new TestDrools(Integer.parseInt(argv[0])).run();
      }
      catch (Exception ex) {
        ex.printStackTrace();
      }
    }
    else
      System.out.println("Usage: TestDrool [# of packages]");
  }
}

package test;
/**
 * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
 * Settings | File Templates.
 */
public class TestObject {
  private String  value1;
  private String  value2;
  private String  result;

  public String getValue1()             { return value1; }
  public void setValue1(String value1)  { this.value1 = value1; }

  public String getValue2()             { return value2; }
  public void setValue2(String value2)  { this.value2 = value2; }

  public String getResult()             { return result; }
  public void setResult(String result)  { this.result = 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 lists.jboss.org  Thu Aug  2 17:10:49 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 2 Aug 2007 17:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8223704.1186089049347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=all ]

Ming Jin updated JBRULES-1056:
------------------------------

    Attachment: testdrools.zip

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Thu Aug  2 18:55:49 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Aug 2007 18:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4591) Create a generic way
 to createDestinations on MDB Container
Message-ID: <32782847.1186095349327.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a generic way to createDestinations on MDB Container
-----------------------------------------------------------

                 Key: JBAS-4591
                 URL: http://jira.jboss.com/jira/browse/JBAS-4591
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JB5-Messaging
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.4.0.CR1


We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ.

The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods.


Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName))

or

createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 19:43:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 2 Aug 2007 19:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-942) support
 RemoteBindings annotations from ejb3-interceptors-aop.xml
In-Reply-To: <32737832.1176490394682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32016073.1186098229465.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-942?page=all ]

William DeCoste closed EJBTHREE-942.
------------------------------------

    Fix Version/s: AS 4.2.2.GA
       Resolution: Done

> support RemoteBindings annotations from ejb3-interceptors-aop.xml
> -----------------------------------------------------------------
>
>                 Key: EJBTHREE-942
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-942
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - FD, EJB 3.0 RC9 - Patch 1, AS 4.2.0 GA
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.GA
>
>
> The proxy is being created and deployed before the EJBContainer is being started, so the annotations are not populated early enough. See EJBContainer.start()
> { 
> initializeClassContainer();
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  2 20:04:53 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 2 Aug 2007 20:04:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-878) correct ejb3
 testsuite so that all "expected" failures do not ... well ... fail
In-Reply-To: <2941304.1171493610200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23797928.1186099493295.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-878?page=all ]

William DeCoste closed EJBTHREE-878.
------------------------------------

    Resolution: Out of Date

> correct ejb3 testsuite so that all "expected" failures do not ... well ... fail
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-878
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-878
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.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 lists.jboss.org  Fri Aug  3 03:36:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1620) location on
 signoOut method is ignored
Message-ID: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>

location on signoOut method is ignored
--------------------------------------

                 Key: JBPORTAL-1620
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final
            Reporter: Thomas Heute
         Assigned To: Thomas Heute
             Fix For: 2.6.2 Final


When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:36:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18915848.1186126609809.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1620?page=all ]

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Summary: location on signOut method is ignored  (was: location on signoOut method is ignored)

> location on signOut method is ignored
> -------------------------------------
>
>                 Key: JBPORTAL-1620
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:46:54 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1514079.1186127214051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1620?page=all ]

Thomas Heute resolved JBPORTAL-1620.
------------------------------------

    Resolution: Done

> location on signOut method is ignored
> -------------------------------------
>
>                 Key: JBPORTAL-1620
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:46:54 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4640968.1186127214179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1620?page=all ]

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Fix Version/s: 2.8 Final

> location on signOut method is ignored
> -------------------------------------
>
>                 Key: JBPORTAL-1620
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 03:46:54 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 03:46:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <296351.1186127214476.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1620?page=all ]

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Fix Version/s:     (was: 2.8 Final)

> location on signOut method is ignored
> -------------------------------------
>
>                 Key: JBPORTAL-1620
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:06:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 3 Aug 2007 04:06:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1620) location on
 signOut method is ignored
In-Reply-To: <19937936.1186126609537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32558114.1186128409776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1620?page=all ]

Thomas Heute updated JBPORTAL-1620:
-----------------------------------

    Attachment: portal-core-lib.jar

Patched jar

> location on signOut method is ignored
> -------------------------------------
>
>                 Key: JBPORTAL-1620
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: portal-core-lib.jar
>
>
> When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:37:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 3 Aug 2007 04:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26727632.1186130269363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12370982 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

I don't understand. What are the exact issues you have? Why do you have to give different priorities to the nodes?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:46:40 2007
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 3 Aug 2007 04:46:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <19847696.1186130800262.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-681?page=comments#action_12370983 ] 
            
Bernd Ruecker commented on JBPM-681:
------------------------------------

I like the proposed solution from "nlebas" in the forum:

---
Simply replacing :
list name="exceptionHandlers" cascade="all"
by :
list name="exceptionHandlers" cascade="all" lazy="false" 

in all hibernate mapping files (*.hbm.xml) seem to have solved the problem for me.
I can't figure out why an exception handler should be lazy-loaded anyway. It seems so unsafe... 
---

Also I think it should not be a performance problem, the most projects I now don't you a lot of exception handlers.

I changed it on my machine, Tom, what do you think, commit it?


> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 04:57:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 04:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-130) Problems with
	reincarnation
Message-ID: <647329.1186131421425.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-130?page=all ]

Bela Ban resolved JGRP-130.
---------------------------

    Resolution: Done

Rejecting a new member who wants to join under the identity of an existing member solves the reincarnation issue

> Problems with reincarnation
> ---------------------------
>
>                 Key: JGRP-130
>                 URL: http://jira.jboss.com/jira/browse/JGRP-130
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: tcp.xml
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:05:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 3 Aug 2007 05:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <11676832.1186131949412.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-681?page=comments#action_12370987 ] 
            
Ronald van Kuijk commented on JBPM-681:
---------------------------------------

Bernd, Issues that do not have a 'fix version' tend to fall of the radar (unless many people vote for it). So either assign a 'fix version' which you think is reasonable and have Tom or any other person change this or have many people vote for it. 

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:08:04 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 3 Aug 2007 05:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <1895009.1186132084494.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-681?page=comments#action_12370988 ] 
            
Ronald van Kuijk commented on JBPM-681:
---------------------------------------

Or indeed commit it (but still assign a fix version to it so it will be in the releasenotes)

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:09:49 2007
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 3 Aug 2007 05:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <30113935.1186132189562.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-681?page=all ]

Bernd Ruecker updated JBPM-681:
-------------------------------

    Fix Version/s: jBPM jPDL 3.2.2

No problem, assigned it and comitted it

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM jPDL 3.2.2
>
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:09:49 2007
From: jira-events at lists.jboss.org (Bernd Ruecker (JIRA))
Date: Fri, 3 Aug 2007 05:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPM-681)
 GraphElement.raiseException results in Exception with Java EE
Message-ID: <24439302.1186132190009.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-681?page=all ]

Bernd Ruecker resolved JBPM-681.
--------------------------------

    Resolution: Done

> GraphElement.raiseException results in Exception with Java EE
> -------------------------------------------------------------
>
>                 Key: JBPM-681
>                 URL: http://jira.jboss.com/jira/browse/JBPM-681
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Java EE with JTA
>            Reporter: Bernd Ruecker
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM jPDL 3.2.2
>
>
> If you
> - invoke a SessionBean in a jbpm action
> - jBPM and the SessionBean run in the same JTA transaction
> - a Exception occurs
> Then the Transaction is marked for rollback from the EJB-Container when the Exception occurs in the SessionBean.
> Now jBPM wants to handle the Exception (see http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#exceptionhandling):
> When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed
> But becaue the transaction is already marked for rollback, a call to Hibernate (lazy loading?) results in a exception:
> 7:14:29,875 INFO  [DefaultLoadEventListener] Error performing load command
> org.hibernate.exception.GenericJDBCException: Cannot open connection
> 	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103
> )
> 	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> 	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> 	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:420)
> 	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
> 	at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
> 	at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:661)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> 	at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
> 	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
> 	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
> 	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.jav
> a:370)
> 	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:81)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:829)
> 	at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
> 	at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:160)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.equals(<generated>)
> 	at org.jbpm.util.EqualsUtil.equals(EqualsUtil.java:30)
> 	at org.jbpm.graph.def.GraphElement.equals(GraphElement.java:418)
> 	at org.jbpm.graph.def.GraphElement$$FastClassByCGLIB$$7a7d6aa6.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.node.TaskNode$$EnhancerByCGLIB$$78d101e.equals(<generated>)
> 	at org.jbpm.graph.def.Transition.getParent(Transition.java:204)
> 	at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:338)
> 	at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:248)
> 	at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212)
> 	at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182)
> 	at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166)
> 	at org.jbpm.graph.def.Transition.take(Transition.java:106)
> 	at org.jbpm.graph.def.Node.leave(Node.java:382)
> 	at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:198)
> 	at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb896060.leave(<generated>)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:174)
> 	at org.jbpm.graph.exe.Token.signal(Token.java:145)
> 	at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$fae2cddc.signal(<generated>)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:420)
> 	at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:359)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$FastClassByCGLIB$$cb2c21af.invoke(<generated>)
> 	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 	at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 	at org.jbpm.taskmgmt.exe.TaskInstance$$EnhancerByCGLIB$$cbd8230f.end(<generated>)
> 	at com.camunda.toolkit.jbpm.service.AdminServicesImpl.endTask(AdminServicesImpl.java:1452)
> 	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:19:04 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-129) Logical addresses
Message-ID: <23800726.1186132744505.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-129?page=comments#action_12370994 ] 
            
Bela Ban commented on JGRP-129:
-------------------------------

With respect to shunning: a shunned member leaves the cluster and rejoins under a new address. So, although it is the same process, the address changes.

> Logical addresses
> -----------------
>
>                 Key: JGRP-129
>                 URL: http://jira.jboss.com/jira/browse/JGRP-129
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough:
> - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper
> - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC
> - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on
> - Network Address Translation: the sender's address might get changed by the NAT
> DESIGN: 
> - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called.
> - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true").
> - The logical addresses must be picked such that they cannot be reused after disconnect()/close().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:19:04 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-129) Logical addresses
Message-ID: <1111272.1186132744638.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-129?page=all ]

Bela Ban updated JGRP-129:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Moved to 2.x, so we can revisit the need for logical addresses. My guess is this issue will get closed in 2.x though, unless someone brings forward a compelling reason to implement logical addresses

> Logical addresses
> -----------------
>
>                 Key: JGRP-129
>                 URL: http://jira.jboss.com/jira/browse/JGRP-129
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough:
> - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper
> - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC
> - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on
> - Network Address Translation: the sender's address might get changed by the NAT
> DESIGN: 
> - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called.
> - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true").
> - The logical addresses must be picked such that they cannot be reused after disconnect()/close().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 05:22:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 05:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-408) Expose classes,
 attributes and
 operations via @ManagedResource, @ManagedAttribute and @ManagedOperation
In-Reply-To: <745914.1168605592586.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2002603.1186132969321.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-408?page=all ]

Bela Ban updated JGRP-408:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Moved to 2.x. JMX 7 (part of Java 7) includes this feature, so we can use it out of the box in a later version of JGroups, allowing us to remove the parallel JMX class/interface hierarchy

> Expose classes, attributes and operations via @ManagedResource, @ManagedAttribute and @ManagedOperation
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-408
>                 URL: http://jira.jboss.com/jira/browse/JGRP-408
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> We should be able to simply make an object expose management information by annotating it. 
> Input: annotations and classes
> Output: classes which are registered with the platform MBeanServer at runtime using an API (which is also provided). This API
> uses the annotations and reflection to create DynamicMBeans (or MXBeans ?) which are then registered with the MBeanServer.
> Example:
> @ManagedResource(objectName="jgroups:type=protocol;name=UDP")
> public class UDP extends Protocol {
>   @ManagedAttribute(name="Sent", descr="Number of bytes sent")
>   long sent_msgs=0; // generates a 'public long getSent()' getter, *no* setter !
>   @ManagedOperation(description="Prints statistics over the last N seconds")
>   @Parameters({@Parameter(name="timeframe", description="Number of milliseconds (0 for all stats)")})
>   public String printStats(long timeframe)  {
>      // implement;
>   }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 06:03:49 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 3 Aug 2007 06:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-430)
 ConcurrentModificationException in
 JoinpointSimpleClassifier.classifyJoinpoint
In-Reply-To: <14240559.1182869818277.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28683239.1186135429949.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-430?page=all ]

Kabir Khan closed JBAOP-430.
----------------------------

    Resolution: Done

> ConcurrentModificationException in JoinpointSimpleClassifier.classifyJoinpoint
> ------------------------------------------------------------------------------
>
>                 Key: JBAOP-430
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-430
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.5.GA
>         Environment: JBossAS 4.2.0.GA
> Sun JDK 1.5.0_11 (build 1.5.0_11-b03)
>            Reporter: Bart Vanhaute
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta, 1.5.6.GA
>
>
> With Load time weaving enabled, a ConcurrentModificationException is printed out in the jboss log output (probably a e.printStackTrace() somewhere). 
> Luckily, the code that I want AOP interceptors applied to is indeed woven. So this is not a big issue for me (at the moment).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 07:09:49 2007
From: jira-events at lists.jboss.org (Nishant Jain (JIRA))
Date: Fri, 3 Aug 2007 07:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1159) Issue while using
 "JBossTransactionManagerLookup" as a
 TransactionManagerLookupClass in JBOSS CACHE
Message-ID: <13577806.1186139389501.JavaMail.jira@cloud.prod.atl2.jboss.com>

Issue while using "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in JBOSS CACHE
---------------------------------------------------------------------------------------------------

                 Key: JBCACHE-1159
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1159
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 1.4.1.SP3
            Reporter: Nishant Jain
         Assigned To: Manik Surtani


We are facing the following error while switching from  "DummyTransactionManagerLookup"   to "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in the configuration file (treecache-config.xml) . Could someone help us out in this?


15:15:06,541 ERROR [JBossCacheManager] JBossCacheService to Tomcat clustering not found
15:15:06,541 ERROR [TomcatDeployer] Failed to setup clustering, clustering disabled
15:15:07,634 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManager is null
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3627)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3608)
15:15:07,634 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.getFromCache(TreeCacheProviderImpl.java:105)
15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCitiesFromCache(CitiesCacheManager.java:52)
15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:39)
15:15:07,634 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
15:15:07,634 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
ava:322)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
ntroller.java:262)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
3)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
erAdapter.java:44)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
:107)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
va:72)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
ationFilter.java:195)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
15:15:07,634 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
38)
15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
)
15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
l.java:744)
15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
15:15:07,634 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
15:15:07,634 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
15:15:07,634 INFO  [STDOUT]     ... 56 more
15:15:07,681 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManage
r is null
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.put(TreeCache.java:3833)
15:15:07,681 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.addToCache(TreeCacheProviderImpl.java:75)
15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.putCitiesInCache(CitiesCacheManager.java:72)
15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:42)
15:15:07,681 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
15:15:07,681 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
ava:322)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
ntroller.java:262)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
3)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
erAdapter.java:44)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
:107)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
va:72)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
ationFilter.java:195)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
15:15:07,681 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
38)
15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
2)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
)
15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
l.java:744)
15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
15:15:07,681 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
15:15:07,681 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
15:15:07,681 INFO  [STDOUT]     ... 55 more
15:15:07,899 INFO  [ResourceBundleThemeSource] Theme created: name 'theme', basename [theme]
15:15:07,899 INFO  [ExpressionEvaluationUtils] Using JSP 2.0 ExpressionEvaluator
15:15:56,871 INFO  [Server] Runtime shutdown hook called, forceHalt: true
15:15:56,871 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 07:18:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 3 Aug 2007 07:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1057) properties
 keyword list is missing memberof
Message-ID: <11968073.1186139929349.JavaMail.jira@cloud.prod.atl2.jboss.com>

properties keyword list is missing memberof
-------------------------------------------

                 Key: JBRULES-1057
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1057
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


Can you liaise with Edson, make sure all the correct properties are in syntax highlighting and auto completion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 08:19:50 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Fri, 3 Aug 2007 08:19:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2958226.1186143590016.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=all ]

Tobias Roth reopened JBPORTAL-1592:
-----------------------------------

             
Maybe I am misunderstanding something, but I still think there is a bug around. The filter you posted works and all, but in a real-world scenario, that's not what one would use for a filter. The filter is constructed by the code, one would not directly add LastName, FirstName for a filter, or only that specific user would be found.

If you look at the log snippets I pasted in a previous post, here is what happens: The user enters his credentials in the login box. The code finds the record for that user, and from that record, it takes the DN. From that DN (which may contain a comma), it constructs the search filter to search for roles. Now, if the DN does contain a comma, no roles are found, because the code does not escape the comma correctly. There is no way I can fix this by adapting the filters in my config, or am I missing something? 

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Fri Aug  3 09:27:57 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 09:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29121481.1186147677104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-510?page=all ]

Bela Ban updated JGRP-510:
--------------------------

    Description: 
NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.

The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 

If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.

When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.

OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.

RESULT: message retransmission is more dynamic:
- Retransmit timeout is *per sender*
- On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
- On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

  was:
NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.

The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 

If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached.

When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.

OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.

RESULT: message retransmission is more dynamic:
- Retransmit timeout is *per sender*
- On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
- On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic


> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 09:32:50 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Fri, 3 Aug 2007 09:32:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1159) Issue while using
 "JBossTransactionManagerLookup" as a
 TransactionManagerLookupClass in JBOSS CACHE
In-Reply-To: <13577806.1186139389501.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10805428.1186147970093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1159?page=all ]

Manik Surtani closed JBCACHE-1159.
----------------------------------

    Resolution: Rejected

Please don't create JIRA issues until we have confirmed that it is in fact a bug on the forums.

> Issue while using "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in JBOSS CACHE
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1159
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1159
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.1.SP3
>            Reporter: Nishant Jain
>         Assigned To: Manik Surtani
>
> We are facing the following error while switching from  "DummyTransactionManagerLookup"   to "JBossTransactionManagerLookup" as a TransactionManagerLookupClass in the configuration file (treecache-config.xml) . Could someone help us out in this?
> 15:15:06,541 ERROR [JBossCacheManager] JBossCacheService to Tomcat clustering not found
> 15:15:06,541 ERROR [TomcatDeployer] Failed to setup clustering, clustering disabled
> 15:15:07,634 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManager is null
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3627)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.get(TreeCache.java:3608)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.getFromCache(TreeCacheProviderImpl.java:105)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCitiesFromCache(CitiesCacheManager.java:52)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:39)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
> ava:322)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
> ntroller.java:262)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
> 3)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
> erAdapter.java:44)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
> 15:15:07,634 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
> 15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 15:15:07,634 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
> :107)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
> va:72)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
> ationFilter.java:195)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> 15:15:07,634 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
> 38)
> 15:15:07,634 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
> )
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
> l.java:744)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 15:15:07,634 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 15:15:07,634 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
> 15:15:07,634 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
> 15:15:07,634 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
> 15:15:07,634 INFO  [STDOUT]     ... 56 more
> 15:15:07,681 INFO  [STDOUT] java.lang.RuntimeException: java.lang.Exception: Failed to create local transaction; TransactionManage
> r is null
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.put(TreeCache.java:3833)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.cache.manager.TreeCacheProviderImpl.addToCache(TreeCacheProviderImpl.java:75)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.putCitiesInCache(CitiesCacheManager.java:72)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.cities.CitiesCacheManager.getCities(CitiesCacheManager.java:42)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.delegate.FlightSearchDelegate.getCities(FlightSearchDelegate.java:65)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.controller.FlightSearchController.showForm(FlightSearchController.java:432)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.showNewForm(AbstractFormController.j
> ava:322)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormCo
> ntroller.java:262)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:15
> 3)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandl
> erAdapter.java:44)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:723)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
> 15:15:07,681 INFO  [STDOUT]     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
> 15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 15:15:07,681 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:25
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java
> :107)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.ja
> va:72)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegr
> ationFilter.java:195)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> 15:15:07,681 INFO  [STDOUT]     at com.tg.acegi.FilterProxy.doFilter(FilterProxy.java:46)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:1
> 38)
> 15:15:07,681 INFO  [STDOUT]     at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:20
> 2)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159
> )
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protoco
> l.java:744)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 15:15:07,681 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 15:15:07,681 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:595)
> 15:15:07,681 INFO  [STDOUT] Caused by: java.lang.Exception: Failed to create local transaction; TransactionManager is null
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.createLocalTx(TxInterceptor.java:980)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:357)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 15:15:07,681 INFO  [STDOUT]     at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
> 15:15:07,681 INFO  [STDOUT]     ... 55 more
> 15:15:07,899 INFO  [ResourceBundleThemeSource] Theme created: name 'theme', basename [theme]
> 15:15:07,899 INFO  [ExpressionEvaluationUtils] Using JSP 2.0 ExpressionEvaluator
> 15:15:56,871 INFO  [Server] Runtime shutdown hook called, forceHalt: true
> 15:15:56,871 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 09:56:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Fri, 3 Aug 2007 09:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7561405.1186149409366.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371016 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

i have several different node (semantic not xml) types and when i gave them the same priority, they all used the same mapper. the other mappers dont look like theyre getting called. when i change the priority it looks like they get called.

here are a couple of elements that interfere with each other:

      <mapping
            adapterClass="com.nexusbpm.editor.xml.EmailSenderNodeDomAdapter"
            id="org.jbpm.gd.jpdl.emailSenderNode"
            mapperClass="com.nexusbpm.editor.xml.EmailSenderNodeDomMapper"
            mapperClassPriority="-98"
            semanticElement="org.jbpm.gd.jpdl.emailSenderNode"
            xmlElement="node"/>
      <mapping
            adapterClass="com.nexusbpm.editor.xml.RNodeDomAdapter"
            id="org.jbpm.gd.jpdl.rNode"
            mapperClass="com.nexusbpm.editor.xml.RNodeDomMapper"
            mapperClassPriority="-97"
            semanticElement="org.jbpm.gd.jpdl.rNode"
            xmlElement="node"/>

if i put the two elements at the same priority only one gets identified.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 10:24:49 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 3 Aug 2007 10:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4591) Create a generic
 way to createDestinations on MDB Container
In-Reply-To: <32782847.1186095349327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <659284.1186151089537.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4591?page=comments#action_12371018 ] 
            
Adrian Brock commented on JBAS-4591:
------------------------------------

Were is this the discussion thread for this?

If you do it, don't change the MDB to enable this by default.

I deprecated this whole feature in JBoss4 and disabled in JBoss5.
Not because it is JBossMQ specific but because it leads to broken behaviour.

See where this has been discussed it before in the JCA and EJB design forums for why this is a bad idea!



> Create a generic way to createDestinations on MDB Container
> -----------------------------------------------------------
>
>                 Key: JBAS-4591
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4591
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JB5-Messaging
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.4.0.CR1
>
>
> We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ.
> The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods.
> Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName))
> or
> createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:13:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 3 Aug 2007 11:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4591) Create a generic way
 to createDestinations on MDB Container
In-Reply-To: <32782847.1186095349327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3904392.1186153981485.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4591?page=all ]

Clebert Suconic updated JBAS-4591:
----------------------------------

    Fix Version/s:     (was:  JBossAS-5.0.0.Beta3)

> Create a generic way to createDestinations on MDB Container
> -----------------------------------------------------------
>
>                 Key: JBAS-4591
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4591
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JB5-Messaging
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.4.0.CR1
>
>
> We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ.
> The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods.
> Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName))
> or
> createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:13:02 2007
From: jira-events at lists.jboss.org (Anton Melser (JIRA))
Date: Fri, 3 Aug 2007 11:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-130) Problems with
	reincarnation
Message-ID: <220354.1186153982679.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12371050 ] 
            
Anton Melser commented on JGRP-130:
-----------------------------------

This is resolved...is there a release with the new code in it? Do I need to compile from svn?

> Problems with reincarnation
> ---------------------------
>
>                 Key: JGRP-130
>                 URL: http://jira.jboss.com/jira/browse/JGRP-130
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: tcp.xml
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:20:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Aug 2007 11:20:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-130) Problems with
	reincarnation
Message-ID: <26180391.1186154449591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12371059 ] 
            
Bela Ban commented on JGRP-130:
-------------------------------

Yes, to test this, you'll need to check out the code from CVS as described in http://sourceforge.net/cvs/?group_id=6081.

This is in CVS head (will be 2.6)

> Problems with reincarnation
> ---------------------------
>
>                 Key: JGRP-130
>                 URL: http://jira.jboss.com/jira/browse/JGRP-130
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.9
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: tcp.xml
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 11:32:49 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 3 Aug 2007 11:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-388) Allow specification
 of the exception for after-throwing and finally bindings
In-Reply-To: <12227475.1176743158464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10545520.1186155169956.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-388?page=all ]

Flavia Rainone updated JBAOP-388:
---------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115234

> Allow specification of the exception for after-throwing and finally bindings
> ----------------------------------------------------------------------------
>
>                 Key: JBAOP-388
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-388
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Flavia Rainone
>         Assigned To: Flavia Rainone
>             Fix For: 2.0.0.beta
>
>
> We need to provide an optional attribute to the throwing/finally tags (and to the corrersponding annotation, if it has already been implemented JBAOP-386), so the user can specify an exception type.
> This task includes updating:
> - advice validation algorithm
> - overloaded advice selection algorithm
> - documentation (tutorial, reference manual, 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 lists.jboss.org  Fri Aug  3 11:35:07 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 3 Aug 2007 11:35:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1035) Deploy sources
 jars on mvn deploy
In-Reply-To: <5448191.1185618355146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20743874.1186155307027.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1035?page=all ]

Geoffrey De Smet resolved JBRULES-1035.
---------------------------------------

    Resolution: Done
      Assignee: Geoffrey De Smet  (was: Mark Proctor)

fixed

> Deploy sources jars on mvn deploy
> ---------------------------------
>
>                 Key: JBRULES-1035
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1035
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 4.0.1
>
>         Attachments: sources.patch
>
>
> Because the maven-source-plugin isn't attached to the default lifecylce, you need to explicitly link it in <plugins>.
> Hope this changes for maven 2.1.
> I also added test-jar sources :)
> In the parent pom I changed this:
>         <plugin>
>           <groupId>org.apache.maven.plugins</groupId>
>           <artifactId>maven-source-plugin</artifactId>
>           <version>2.0.2</version>
> 	        <executions>
> 	          <execution>
> 	            <goals>
> 	              <goal>jar</goal>
> +                     <goal>test-jar</goal>
> 	            </goals>
> 	          </execution>
> 	        </executions>
>         </plugin>
> ...
>     </pluginManagement>
>     <plugins>
> +        <plugin>
> +          <!-- Entry needed to create, install and deploy sources jars -->
> +            <groupId>org.apache.maven.plugins</groupId>
> +            <artifactId>maven-source-plugin</artifactId>
> +        </plugin>
>     </plugins>
>   </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 lists.jboss.org  Fri Aug  3 12:44:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 12:44:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-59) IdentityTrust
	Framework
In-Reply-To: <12983617.1181580311625.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26182340.1186159489511.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-59?page=all ]

Anil Saldhana updated SECURITY-59:
----------------------------------

        Summary: IdentityTrust Framework  (was: TrustManager Interface)
    Component/s: JBossSX

> IdentityTrust Framework
> -----------------------
>
>                 Key: SECURITY-59
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-59
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1.BETA
>
>
> Bring in a Trust Manager Interface reachable from the security context to make trust based decisions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 12:50:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 12:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-59) IdentityTrust
	Framework
In-Reply-To: <12983617.1181580311625.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15808943.1186159849289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-59?page=all ]

Anil Saldhana closed SECURITY-59.
---------------------------------

    Resolution: Done

> IdentityTrust Framework
> -----------------------
>
>                 Key: SECURITY-59
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-59
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1.BETA
>
>
> Bring in a Trust Manager Interface reachable from the security context to make trust based decisions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 13:02:49 2007
From: jira-events at lists.jboss.org (james ahlborn (JIRA))
Date: Fri, 3 Aug 2007 13:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-786) stale sockets can be
 gotten from pool even with current rety logic
Message-ID: <27204054.1186160569605.JavaMail.jira@cloud.prod.atl2.jboss.com>

stale sockets can be gotten from pool even with current rety logic
------------------------------------------------------------------

                 Key: JBREM-786
                 URL: http://jira.jboss.com/jira/browse/JBREM-786
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 1.4.6.GA
            Reporter: james ahlborn


The retry logic in SocketClientInvoker.transport attempts to ensure that the invoker does not get a stale socket on the last attempt by flushing the pool.  however, this only discards any currently unused scokets.  a second invoker could return a stale socket after the flush, causing the first invoker to fail again on the last retry (with an EOFException).  while this seems like an edge case, we can hit it reliably under load with many connections to the same destination.  i've patched this class so that the last call to getConnection will never return a pooled connection.  we never got the EOFException after applying this 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 lists.jboss.org  Fri Aug  3 13:04:49 2007
From: jira-events at lists.jboss.org (james ahlborn (JIRA))
Date: Fri, 3 Aug 2007 13:04:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-786) stale sockets can be
 gotten from pool even with current rety logic
In-Reply-To: <27204054.1186160569605.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4564453.1186160689467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-786?page=all ]

james ahlborn updated JBREM-786:
--------------------------------

    Attachment: remoting-fixes.txt

> stale sockets can be gotten from pool even with current rety logic
> ------------------------------------------------------------------
>
>                 Key: JBREM-786
>                 URL: http://jira.jboss.com/jira/browse/JBREM-786
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.6.GA
>            Reporter: james ahlborn
>         Attachments: remoting-fixes.txt
>
>
> The retry logic in SocketClientInvoker.transport attempts to ensure that the invoker does not get a stale socket on the last attempt by flushing the pool.  however, this only discards any currently unused scokets.  a second invoker could return a stale socket after the flush, causing the first invoker to fail again on the last retry (with an EOFException).  while this seems like an edge case, we can hit it reliably under load with many connections to the same destination.  i've patched this class so that the last call to getConnection will never return a pooled connection.  we never got the EOFException after applying this 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 lists.jboss.org  Fri Aug  3 14:55:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 14:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4592) NPE in
	ExtendedFormAuthenticator
Message-ID: <18543156.1186167349461.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE in ExtendedFormAuthenticator
--------------------------------

                 Key: JBAS-4592
                 URL: http://jira.jboss.com/jira/browse/JBAS-4592
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security, Web (Tomcat) service
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Anil Saldhana
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.2.2.GA


Forum has 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 lists.jboss.org  Fri Aug  3 16:45:03 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Fri, 3 Aug 2007 16:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29111431.1186173903266.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371105 ] 
            
John Ruud commented on GPD-77:
------------------------------

Koen,

Moving the initialize() call to SemanticElementFactory doesn't seem to work for me, for the following reason:

While initialize() is correctly being invoked when dropping something from my palettte:

Decide(AbstractDecide).initialize() line: 21	
SemanticElementFactory.createById(String) line: 30	
CreationFactory.getNewObject() line: 34	
CreateRequest.getNewObject() line: 73
...

it is also invoked as part of reading the diagram (which is not good as it will reset properties that potentially have been modified):

Decide(AbstractDecide).initialize() line: 21	
SemanticElementFactory.createById(String) line: 30	
ProcessDefinitionDomAdapter(XmlAdapter).createSemanticElementFor(XmlAdapter) line: 476	
ProcessDefinitionDomAdapter.doModelAdd(XmlAdapter) line: 157	
ProcessDefinitionDomAdapter(XmlAdapter).initialize(SemanticElement) line: 462	
ProcessDefinitionDomAdapter.initialize(SemanticElement) line: 94	
XpdlEditor(Editor).getSemanticElement(StructuredTextEditor) line: 163	
XpdlEditor(Editor).initSourcePage() line: 145	
XpdlEditor(Editor).createPages() line: 84	
XpdlEditor(JpdlEditor).createPages() line: 134	
XpdlEditor(MultiPageEditorPart).createPartControl(Composite) line: 276	
EditorReference.createPartHelper() line: 596	
EditorReference.createPart() line: 372
...

Invoking initialize() (or possibly named: initializeNew/initializeFromPalette etc.) in org.jbpm.gd.common.editor.CreationFactory DOES work, as it will not get invoked when reading the diagram:

public Object getNewObject() {
		String notationElementId = NotationMapping.getNotationElementId(elementId);
		NotationElement notationElement = notationElementFactory.create(notationElementId);
		if (notationElement instanceof Node) {
			Dimension dimension = NotationMapping.getInitialDimension(elementId);
			if (dimension != null) {
				Rectangle constraint = ((Node)notationElement).getConstraint();
				constraint.setSize(new Dimension(dimension));
			}
		}
		SemanticElement jpdlElement = semanticElementFactory.createById(elementId);
		jpdlElement.initializeNew(); // I added my code here...
		notationElement.setSemanticElement(jpdlElement);
		return notationElement;
	}

Please let me know if you need more info!

John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Fri Aug  3 17:00:49 2007
From: jira-events at lists.jboss.org (tmullett (JIRA))
Date: Fri, 3 Aug 2007 17:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1033) string_max
 parameterization doesn't work
Message-ID: <19022120.1186174849551.JavaMail.jira@cloud.prod.atl2.jboss.com>

string_max parameterization doesn't work 
-----------------------------------------

                 Key: JBPM-1033
                 URL: http://jira.jboss.com/jira/browse/JBPM-1033
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: WIndows XP, Hibernate 3.2.4.sp1, Java 1.4.2
            Reporter: tmullett
         Assigned To: Tom Baeyens


Fields in the hibernate mapping files declared as type "string_max" should be truncated to the parameterized length. The mapping files do this parameterization with a "length" attribute on the property element. It looks like this (from ActionLog.hbm.xml):

<property name="exception"
              type="string_max"
              column="EXCEPTION_"
              length="4000" />

4000 also happens to be what StringMax will use if it can't find or parse its parameterization. We needed to shorten some fields to fit jBpm into MS SQL Server. When we shortened the length, we noticed that the parameter was being ignored, causing jdbc to blow chunks.  org.jbpm.db.hibernate.StringMax.setParameterValues() always gets a null passed in for it's parameters with this setup. To get it to work , we changed it to 

    <property name="exception" column="EXCEPTION_">
		<type name="string_max">
			<param name="length">1000</param>
		</type>
    </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 lists.jboss.org  Fri Aug  3 17:53:53 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 17:53:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-73) Release Security
	V2.0.1-BETA
Message-ID: <14609963.1186178033997.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release Security V2.0.1-BETA
----------------------------

                 Key: SECURITY-73
                 URL: http://jira.jboss.com/jira/browse/SECURITY-73
             Project: JBoss Security and Identity Management
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
    Affects Versions: 2.0.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1.BETA


Release v2.0.1-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 lists.jboss.org  Fri Aug  3 18:00:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 3 Aug 2007 18:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-74) Policy Management
 Console using JBoss SEAM
Message-ID: <14814510.1186178449283.JavaMail.jira@cloud.prod.atl2.jboss.com>

Policy Management Console using JBoss SEAM
------------------------------------------

                 Key: SECURITY-74
                 URL: http://jira.jboss.com/jira/browse/SECURITY-74
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossXACML-Console
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1


Need for a progressive Policy Management console using JBoss SEAM.  The JAXB2 object model provided with JBoss XACML can be used to construct the policies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug  3 18:14:49 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Fri, 3 Aug 2007 18:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
Message-ID: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
---------------------------------------------------------------------------------------

                 Key: GPD-128
                 URL: http://jira.jboss.com/jira/browse/GPD-128
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
            Reporter: John Ruud
         Assigned To: Koen Aers


I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sat Aug  4 04:54:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Sat, 4 Aug 2007 04:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1033) string_max
 parameterization doesn't work
In-Reply-To: <19022120.1186174849551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23279895.1186217689812.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1033?page=comments#action_12371121 ] 
            
Ronald van Kuijk commented on JBPM-1033:
----------------------------------------

can you find out if this is a hibernate version related issue?

> string_max parameterization doesn't work 
> -----------------------------------------
>
>                 Key: JBPM-1033
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1033
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: WIndows XP, Hibernate 3.2.4.sp1, Java 1.4.2
>            Reporter: tmullett
>         Assigned To: Tom Baeyens
>
> Fields in the hibernate mapping files declared as type "string_max" should be truncated to the parameterized length. The mapping files do this parameterization with a "length" attribute on the property element. It looks like this (from ActionLog.hbm.xml):
> <property name="exception"
>               type="string_max"
>               column="EXCEPTION_"
>               length="4000" />
> 4000 also happens to be what StringMax will use if it can't find or parse its parameterization. We needed to shorten some fields to fit jBpm into MS SQL Server. When we shortened the length, we noticed that the parameter was being ignored, causing jdbc to blow chunks.  org.jbpm.db.hibernate.StringMax.setParameterValues() always gets a null passed in for it's parameters with this setup. To get it to work , we changed it to 
>     <property name="exception" column="EXCEPTION_">
> 		<type name="string_max">
> 			<param name="length">1000</param>
> 		</type>
>     </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 lists.jboss.org  Sat Aug  4 13:54:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sat, 4 Aug 2007 13:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22580987.1186250089404.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371137 ] 
            
Koen Aers commented on GPD-128:
-------------------------------

John,

Can you please attach the error log that Eclipse spit out? I need to figure out the 'certain' conditions ;-)

Regards,
Koen

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sat Aug  4 14:58:57 2007
From: jira-events at lists.jboss.org (Mark McNally (JIRA))
Date: Sat, 4 Aug 2007 14:58:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
Message-ID: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>

nested accessors with Sets - "not contains" is not a valid operator for MVEL
----------------------------------------------------------------------------

                 Key: JBRULES-1058
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Mark McNally
         Assigned To: Mark Proctor


Following does not work:

		rule StateMatch
			when
			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
			then 	
				retract( $ca );
		end
		
		
		public class CandidateAssociation {
			private PatientDetails patientDetails;
			private NurseDetails   nurseDetails;
			private int overlapHours;
		
			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
				super();
				this.patientDetails = patientDetails;
				this.nurseDetails = nurseDetails;
				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
			}
		    [...]
		}
		
		public class NurseDetails {
			private Set stateLicensures = new HashSet();
			[...]
		}
		public class PatientDetails {
			private String state;
			[...]
		}

Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 

Also Noticed that the following workaround did not work:

		rule State
		    dialect "mvel"
			when
		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
			then 	
		  	    retract( $ca );
		end
		
		This produced this Exception:
		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
	        at org.drools.rule.Package.checkValidity(Package.java:408)
	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
	        at [...]



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 15:33:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sat, 4 Aug 2007 15:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9552060.1186256029805.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371138 ] 
            
Koen Aers commented on GPD-77:
------------------------------

It may work in this way, but it doesn't feel right as it blurs the lifecycle of the semantic element. Let me think about this and try to come up with a working solution.

Btw. I infer from your previous comment that you guys are doing xpdl on top of jbpm? Can you elaborate on this? Are you planning to contribute something? 

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sat Aug  4 16:56:10 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 16:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
Message-ID: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move network i/o in BisocketClientInvoker constructor to handleConnect()
------------------------------------------------------------------------

                 Key: JBREM-787
                 URL: http://jira.jboss.com/jira/browse/JBREM-787
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 17:10:59 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 17:10:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32302292.1186261859686.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-787?page=comments#action_12371140 ] 
            
Ron Sigal commented on JBREM-787:
---------------------------------

The fix has been applied to branch remoting_2_2_0_GA.

There is no specific unit test.

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 19:15:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 19:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-784) Use separate maps
 for control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32104538.1186269349459.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-784?page=comments#action_12371142 ] 
            
Ron Sigal commented on JBREM-784:
---------------------------------

It's possible that the confusion was due to another issue, JBREM-785.  However, there is still the possibility that the confusion could arise during a switch to a new control connection.

The fix has been applied to branch remoting_2_2_0_GA.

Unit test: org.jboss.test.remoting.transport.bisocket.SeparateControlSocketsTestCase.

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 19:30:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 19:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7392303.1186270202661.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-775?page=all ]

Ron Sigal updated JBREM-775:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.1.GA
                       2.2.0.SP4_CP02

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.1.SP1, 2.2.0.SP4_CP02
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 19:31:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 19:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29880727.1186270309293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-767?page=all ]

Ron Sigal updated JBREM-767:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.1.GA
                       2.2.1.SP1

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Sat Aug  4 22:42:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 22:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
Message-ID: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>

Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
----------------------------------------------------------------------------------------

                 Key: JBREM-788
                 URL: http://jira.jboss.com/jira/browse/JBREM-788
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.1.GA, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug  4 22:46:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sat, 4 Aug 2007 22:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10747642.1186282009547.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-788?page=comments#action_12371143 ] 
            
Ron Sigal commented on JBREM-788:
---------------------------------

The fix has been applied to branch remoting_2_2_0_GA.

There is no specific unit test.

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 00:16:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 00:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29039707.1186287409472.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-767?page=comments#action_12371144 ] 
            
Ron Sigal commented on JBREM-767:
---------------------------------

One fix for this issue is to move network i/o from the BisocketClientInvoker constructor to BisocketClientInvoker.handleCconnect() - JBREM-787.

Another fix is to have BisocketClientInvoker.handleDisconnect() wake up any threads waiting in BisocketClientInvoker.createSocket().  

The fix for the latter has been applied to branch remoting_2_2_0_GA.

Unit test: org.jboss.test.remoting.transport.bisocket.CallbackDisconnectTestCase.

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Sun Aug  5 05:19:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sun, 5 Aug 2007 05:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-448) maven-jbossaop-plugin
 cannot use include of classes
In-Reply-To: <32238332.1185615887062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32156960.1186305589485.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-448?page=all ]

Anders Andersen closed JBAOP-448.
---------------------------------

    Resolution: Done

I have tested the fix now.
It works.

I can see if I add the include it only compiles the classes in the include
If I do not add include it tries to compile everything

I suggest that we  added a debug statement

      if(getLog().isDebugEnabled()) {
          getLog().debug("Execute AOPC compiler command: "+cl.toString());
      }

so maven .... -X displayes the call to the command.

> maven-jbossaop-plugin cannot use include of classes
> ---------------------------------------------------
>
>                 Key: JBAOP-448
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-448
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>         Environment: any maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> The ant target 
>       <taskdef
>          name="aopc"
>          classname="org.jboss.aop.ant.AopC"
>          classpathref="jbossaop.task.classpath"/>
> is cabable of including specific classes
> Sample:
>       <aopc compilerclasspathref="aop.classpath" verbose="true">
>          <classpath refid="aopc.classpath"/>
>          <src path="${build.classes}"/>
>          <aoppath path="${build.resources}/portal-wsrp-sar/wsrp-aop.xml"/>
>          <include name="org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class"/>
>       </aopc>
> Sample of what it could look like in maven2
>       <plugin>
>         <groupId>org.jboss.maven.plugins</groupId>
>         <artifactId>maven-jbossaop-plugin</artifactId>
>         <executions>
>           <execution>
>             <phase>process-classes</phase>
>             <configuration>
>               <aoppath>${basedir}/../portal-wsrp-sar/src/main/resources/wsrp-aop.xml</aoppath>
>               <verbose>true</verbose>
>               <includes>
>                 <include>org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class</include>
>               </includes>
>             </configuration>
>             <goals>
>               <goal>compile</goal>
>             </goals>
>           </execution>
>         </executions>
>       </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 lists.jboss.org  Sun Aug  5 05:19:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sun, 5 Aug 2007 05:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-448)
 maven-jbossaop-plugin cannot use include of classes
In-Reply-To: <32238332.1185615887062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2813508.1186305589651.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-448?page=comments#action_12371150 ] 
            
Anders Andersen commented on JBAOP-448:
---------------------------------------

I would like to know where the plugin is maven deployed.

> maven-jbossaop-plugin cannot use include of classes
> ---------------------------------------------------
>
>                 Key: JBAOP-448
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-448
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>         Environment: any maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> The ant target 
>       <taskdef
>          name="aopc"
>          classname="org.jboss.aop.ant.AopC"
>          classpathref="jbossaop.task.classpath"/>
> is cabable of including specific classes
> Sample:
>       <aopc compilerclasspathref="aop.classpath" verbose="true">
>          <classpath refid="aopc.classpath"/>
>          <src path="${build.classes}"/>
>          <aoppath path="${build.resources}/portal-wsrp-sar/wsrp-aop.xml"/>
>          <include name="org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class"/>
>       </aopc>
> Sample of what it could look like in maven2
>       <plugin>
>         <groupId>org.jboss.maven.plugins</groupId>
>         <artifactId>maven-jbossaop-plugin</artifactId>
>         <executions>
>           <execution>
>             <phase>process-classes</phase>
>             <configuration>
>               <aoppath>${basedir}/../portal-wsrp-sar/src/main/resources/wsrp-aop.xml</aoppath>
>               <verbose>true</verbose>
>               <includes>
>                 <include>org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class</include>
>               </includes>
>             </configuration>
>             <goals>
>               <goal>compile</goal>
>             </goals>
>           </execution>
>         </executions>
>       </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 lists.jboss.org  Sun Aug  5 06:27:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sun, 5 Aug 2007 06:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1615) Maven2 poms
 initial version ready for portal
In-Reply-To: <4157740.1185486047091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28331354.1186309669411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1615?page=all ]

Anders Andersen updated JBPORTAL-1615:
--------------------------------------

    Attachment: _maven-08-05.tar.gz

1) AOPC plugin JIRA JBAOP-448 fixed. Meaning path to classes now works without prefix with maven project location
2) wsrp fixed with this
3) core fixed with this
4) samples fully removed from build

> Maven2 poms initial version ready for portal
> --------------------------------------------
>
>                 Key: JBPORTAL-1615
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1615
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>         Environment: unix script used (use unix or cygwin)
>            Reporter: Anders Andersen
>         Attachments: _maven-08-05.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz
>
>          Time Spent: 1 day, 5 hours
>  Remaining Estimate: 0 minutes
>
> The _maven directory will contain a complete maven2 build environment for the jboss portal
> prepare:
>           If you are running windows --> install cygwin and run bash from here
>           1) #install maven2 (2.0.6) or later
>           2) #install the jboss-packaging-maven-plugin
>              svn co https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/jboss-packaging-maven-plugin jboss-packaging-maven-plugin
>              mvn -f jboss-packaging-maven-plugin/pom.xml install
>           3) #install the portal
>              svn co http://anonsvn.jboss.org/repos/portal/trunk jboos-portal
>              cd jboss-portal
>              build/build.sh clean most
>           4) unzip the _maven into jboss-portal
>           5) cd _maven
>              cd _deploy
>              # deploy the third party artifacts that I did not find on the internet
>              # edit the script to meet your settings before running
>              ./third-party-deploy.sh
>           6) #prepare the maven source locations
> usage:       #run script
>              ./_build.sh
> post steps:
>           7) #maven build the jboss 2.6 portal
>              mvn clean install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 13:21:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 13:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25050997.1186334509336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-765?page=all ]

Ron Sigal updated JBREM-765:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.1.GA
                       2.2.0.SP4_CP02

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 14:53:49 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Sun, 5 Aug 2007 14:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1059) Online typos in
	Section 1
Message-ID: <15111425.1186340029389.JavaMail.jira@cloud.prod.atl2.jboss.com>

Online typos in Section 1
-------------------------

                 Key: JBRULES-1059
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1059
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.MR3
         Environment: n/a  - concerns documentation availble for viewing over internet
            Reporter: Dave Dibble
         Assigned To: Mark Proctor
            Priority: Trivial


miscellaneous typos

http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/index.html

Section 1.1
modiied ? modified
Drools will adding ? Drools will be adding

Section 1.2.1
explination ? explanation
layed ? laid
espically ? especially
knowlegde ? knowledge

Section 1.2.4
preceeding ? preceding
its ? it's

Section 1.3.1
shortley ? shortly

Section 1.3.2
conjuntive ? conjunctive
disjuntive ? disjunctive

Section 1.6.1
grammer ? grammar
deployeable ? deployable
PackagBuilder ? PackageBuilder

Section 1.6.4.6
In the shaded box, should 'new List' simply be 'List' ?

Section 1.6.5
legible ? eligible

section 1.6.6.1
managable ? manageable

section 1.6.7
AgendEventListener ? AgendaEventListener






-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Sun Aug  5 16:23:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21331758.1186345429282.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-765?page=comments#action_12371161 ] 
            
Ron Sigal commented on JBREM-765:
---------------------------------

There is a new configuration parameter, org.jboss.remoting.callback.ServerInvokerCallbackHandler.CALLBACK_TIMEOUT (actual value "callbackTimeout"), which can be used to set the timeout value for server side callback clients.  For callback clients the value associated with CALLBACK_TIMEOUT overrides the value associated with org.jboss.remoting.ServerInvoker.TIMEOUT (actual value "timeout").

There are multiple ways of setting the CALLBACK_TIMEOUT value.  In order of descending priority:

1. it may be put into the metadata map used in the call to org.jboss.remoting.Client.addListener();

2. it may be placed in the server's InvokerLocator;

3. it may be placed in the configuration map passed to the server Connector's constructor.

That is, the value in the metadata map overrides the values in the InvokerLocator and configuration map, and the value in the InvokerLocator overrides the value in the configuration map.

The feature has been implemented in the remoting_2_2_0_GA branch.

Unit tests:  The feature has been tested for the socket and bisocket transports:

    org.jboss.test.remoting.callback.timeout.BisocketCallbackTimeoutTestCase
    org.jboss.test.remoting.callback.timeout.SocketCallbackTimeoutTestCase

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:25:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19173789.1186345549295.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-767?page=comments#action_12371162 ] 
            
Ron Sigal commented on JBREM-767:
---------------------------------

Another fix is to allow a separately configurable timeout value for callback clients (JBREM-765).  That feature has been implemented on the remoting_2_2_0_GA branch.

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Sun Aug  5 16:33:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17687940.1186346029361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal reopened JBREM-779:
-----------------------------

             

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:33:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13792100.1186346029475.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal updated JBREM-779:
----------------------------

        Fix Version/s: 2.4.0.Beta1 (Pinto)
    Affects Version/s: 2.2.0.SP4_CP02
                       2.4.0.Beta1 (Pinto)
                           (was: 2.2.0.SP4)

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:36:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-779) BisocketClientInvoker
 should guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10145035.1186346162103.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal closed JBREM-779.
---------------------------

    Resolution: Done

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:37:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Sun, 5 Aug 2007 16:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16468669.1186346269364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-766?page=all ]

Ron Sigal updated JBREM-766:
----------------------------

        Fix Version/s: 2.2.1.SP1
                       2.2.0.SP4_CP02
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA
                       2.2.0.SP4_CP02

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 16:47:49 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 5 Aug 2007 16:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-678) Remove spring
	dependency
In-Reply-To: <4908345.1171728569969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8859296.1186346869324.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-678?page=comments#action_12371166 ] 
            
Geoffrey De Smet commented on JBRULES-678:
------------------------------------------

A large part has been done, including removing the use of spring's Resource and spring Log4jConfigurer and InitializingBean in the examples.

Only thing that remains is the use of spring to put together the solver. Although it's easy to replace that with plain old java code, the solver configuration is a better solution.

> Remove spring dependency
> ------------------------
>
>                 Key: JBRULES-678
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-678
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Solver
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>
> Once the configuration xml is extracted this should be a peice of cake

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 17:53:02 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Sun, 5 Aug 2007 17:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1709215.1186350782875.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-128?page=all ]

John Ruud updated GPD-128:
--------------------------


Koen,

My stack trace is included (below). While my own classes are involved in this case, it may hopfully be clear by looking at line 43 of XmlAdapterRegistry why the exception occurs (a TreeSet is added to xmlElementMap, but in line 52 this Set is then attempted casted to an IConfigurationElement)

John

!ENTRY org.eclipse.ui 4 4 2007-08-05 14:16:41.843
!MESSAGE Unhandled event loop exception

!ENTRY org.eclipse.ui 4 0 2007-08-05 14:16:41.890
!MESSAGE java.util.TreeSet cannot be cast to org.eclipse.core.runtime.IConfigurationElement
!STACK 0
java.lang.ClassCastException: java.util.TreeSet cannot be cast to org.eclipse.core.runtime.IConfigurationElement
	at org.jbpm.gd.common.registry.XmlAdapterRegistry.getConfigurationElementByXmlElementName(XmlAdapterRegistry.java:52)
	at com.thrasys.gd.xpdl.model.ModelFactory.getSemanticElementId(ModelFactory.java:53)
	at com.thrasys.gd.xpdl.model.ModelFactory.createByElementId(ModelFactory.java:60)
	at com.thrasys.gd.xpdl.model.ModelFactory.addXNetXml(ModelFactory.java:92)
	at com.thrasys.gd.xpdl.model.Node.initializeNew(Node.java:9)
	at org.jbpm.gd.common.editor.CreationFactory.getNewObject(CreationFactory.java:35)
	at org.eclipse.gef.requests.CreateRequest.getNewObject(CreateRequest.java:73)
	at org.jbpm.gd.common.policy.XYLayoutEditPolicy.initCreateCommand(XYLayoutEditPolicy.java:58)
	at org.jbpm.gd.common.policy.XYLayoutEditPolicy.getCreateCommand(XYLayoutEditPolicy.java:42)
	at org.eclipse.gef.editpolicies.LayoutEditPolicy.getCommand(LayoutEditPolicy.java:199)
	at org.eclipse.gef.editpolicies.ConstrainedLayoutEditPolicy.getCommand(ConstrainedLayoutEditPolicy.java:154)
	at org.eclipse.gef.editparts.AbstractEditPart.getCommand(AbstractEditPart.java:473)
	at org.eclipse.gef.tools.TargetingTool.getCommand(TargetingTool.java:122)
	at org.eclipse.gef.tools.CreationTool.handleMove(CreationTool.java:239)
	at org.eclipse.gef.tools.AbstractTool.mouseMove(AbstractTool.java:1038)
	at org.eclipse.gef.EditDomain.mouseMove(EditDomain.java:248)
	at org.eclipse.gef.ui.parts.DomainEventDispatcher.dispatchMouseMoved(DomainEventDispatcher.java:359)
	at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseMove(LightweightSystem.java:533)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:145)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1930)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:422)
	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(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	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)

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sun Aug  5 17:56:49 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Sun, 5 Aug 2007 17:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24076381.1186351009357.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371169 ] 
            
John Ruud commented on GPD-77:
------------------------------

I've been experimenting with (on and off) adding GD support for "xpdl", which would become a domain specific "extension" of jpdl. Because of its proprietary nature it wouldn't be very useful to the general public. I plan to keep contributing patches and post feature requests that would make it possible/easier to use GD for editing "xpdl",  and this would hopfully also make it easier for other developers to add support for their own dsls. Does this sound like a good approach?

Thanks, John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sun Aug  5 18:13:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sun, 5 Aug 2007 18:13:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18755405.1186352029370.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371170 ] 
            
Koen Aers commented on GPD-77:
------------------------------

xpdl is a public standard so it is definitely not proprietary. 

xpdl support is on the roadmap of our new pvm approach. we are collaborating with the guys from the bonita engine and with the eclipse jwt project to get this going. 

or is this a name clash? 

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sun Aug  5 18:26:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Sun, 5 Aug 2007 18:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29451035.1186352761896.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371171 ] 
            
John Ruud commented on GPD-77:
------------------------------

LOL - it's a name clash (guess I need to come up with something more original)

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Sun Aug  5 19:05:49 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 5 Aug 2007 19:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3439170.1186355149492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen reassigned JBAOP-449:
------------------------------------

    Assignee: Stale Pedersen

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Sun Aug  5 19:10:02 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 5 Aug 2007 19:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25614314.1186355402453.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-449?page=comments#action_12371173 ] 
            
Stale Pedersen commented on JBAOP-449:
--------------------------------------

it should work as ant do, eg just add the files in the same element separated by the "File.pathSeparator". - but this isnt very portable and we'll look into it before the release of 2.0.

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Sun Aug  5 19:10:02 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 5 Aug 2007 19:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-447) maven-jbossaop-plugin
 uses wrong location of target/classes
In-Reply-To: <32850547.1185615647354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27611487.1186355402693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-447?page=all ]

Stale Pedersen closed JBAOP-447.
--------------------------------


> maven-jbossaop-plugin uses wrong location of target/classes
> -----------------------------------------------------------
>
>                 Key: JBAOP-447
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-447
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: unix OSX 10.4.10
> java 1.5
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> the plugin uses target/classes as the location of classes.
> This is wrong when you use mvn -f xxxxx/pom.xml clean process-classes
> class: maven-jbossaop-plugin/src/main/java/org/jboss/maven/plugins/JBossAOPCMojo.java
> code error ****
>       if(isTest())
>          cl.addArguments(new String[] { project.getBuild().getTestOutputDirectory()});
>       else
>          cl.addArguments(new String[] { "target/classes"});
> better code******
>       if(isTest())
>          cl.addArguments(new String[] { project.getBuild().getTestOutputDirectory()});
>       else
>          cl.addArguments(new String[] { project.getBuild().getOutputDirectory()});

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug  5 22:29:49 2007
From: jira-events at lists.jboss.org (christopher barham (JIRA))
Date: Sun, 5 Aug 2007 22:29:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
Message-ID: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unexpected exit with no stack trace or other information
--------------------------------------------------------

                 Key: JBRULES-1060
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
            Reporter: christopher barham
         Assigned To: Mark Proctor


When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.

Garbage.java (fact bean):

package com.sample;

public class Garbage {
    private char id;

    private int someNumber;

    public Garbage(char garbageId, int someNumber) {
        setSomeNumber(someNumber);
        setId(garbageId);
    }

    public char getId() {
        return id;
    }

    public int getSomeNumber() {
        return someNumber;
    }

    public void setId(char id) {
        this.id = id;
    }

    public void setSomeNumber(int someNumber) {
        this.someNumber = someNumber;
    }

    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder();
        sb.append("a Garbage { ");
        sb.append("someNumber= ");
        sb.append(getSomeNumber());
        sb.append(", id= ");
        sb.append(getId());
        sb.append(" }");
        return sb.toString();
    }

}

StrangeExit.Java (Rule Engine startup and fact insertion):

package com.sample;

import java.io.InputStreamReader;
import java.io.Reader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;
import org.drools.event.DebugWorkingMemoryEventListener;
import org.drools.rule.Package;

public class StrangeExit {

    public static final void main(String[] args) {
        try {
            long startTime = System.currentTimeMillis();
            System.out.println("Starting problem at " + new java.util.Date());
            RuleBase ruleBase = readRule();
            WorkingMemory workingMemory = ruleBase.newStatefulSession();

            workingMemory.addEventListener(new DebugWorkingMemoryEventListener());

            assertAllFacts(workingMemory);

            workingMemory.fireAllRules();

            long stopTime = System.currentTimeMillis();
            long runTime = stopTime - startTime;
            System.out.println("Run time (milliseconds): " + runTime);
            System.out.println("Finished problem at " + new java.util.Date());
        } catch (Throwable t) {
            t.printStackTrace();
        }
    }

    private static void assertAllFacts(WorkingMemory workingMemory) {
        for (int i = 1; i <= 3; i++) {
            for (int j = 1; j <= 475; j++) {
                Garbage gar = new Garbage((char)(i + 64), j);
                workingMemory.insert(gar);
            }
        }
    }

    private static RuleBase readRule() throws Exception {
        Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
        PackageBuilder builder = new PackageBuilder();
        builder.addPackageFromDrl(source);
        Package pkg = builder.getPackage();
        RuleBase ruleBase = RuleBaseFactory.newRuleBase();
        ruleBase.addPackage(pkg);
        return ruleBase;
    }
}


The Rule itself:

package com.sample

import com.sample.Garbage;

rule "Weird exit with no stack trace error"
  when
    $garA : Garbage(  )
    $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
  then
    System.out.println("Something is up");
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 lists.jboss.org  Sun Aug  5 22:33:53 2007
From: jira-events at lists.jboss.org (christopher barham (JIRA))
Date: Sun, 5 Aug 2007 22:33:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7850956.1186367633369.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=all ]

christopher barham updated JBRULES-1060:
----------------------------------------

    Attachment: strangeExit.zip

Small example demonstrating the exit issue

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Mon Aug  6 00:07:06 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 6 Aug 2007 00:07:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13864174.1186373226943.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-766?page=comments#action_12371177 ] 
            
Ron Sigal commented on JBREM-766:
---------------------------------

Changes have been made to the following:

   - org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket()
   - org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnection()
   - org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection()
   - org.jboss.remoting.transport.socket.ServerThread.run()
   - org.jboss.remoting.transport.socket.SocketServerInvoker.ServerSocketRefresh

The changes have been applied to the remoting_2_2_0_GA branch.

There are no specific unit tests.

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 03:43:49 2007
From: jira-events at lists.jboss.org (Pavel Myshkin (JIRA))
Date: Mon, 6 Aug 2007 03:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1621) "title"
 attribute of "link" tag in jboss-portlet.xml is unhandled
Message-ID: <30538884.1186386229579.JavaMail.jira@cloud.prod.atl2.jboss.com>

"title" attribute of "link" tag in jboss-portlet.xml is unhandled
-----------------------------------------------------------------

                 Key: JBPORTAL-1621
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1621
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: JBoss Portal 2.6.1 GA bundled
            Reporter: Pavel Myshkin


JBOSS-PORTLET.XML
--------------------------------
<!DOCTYPE portlet-app PUBLIC
   "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
   "dtd/jboss-portlet_2_6.dtd">
<portlet-app>
<portlet>
<portlet-name>PortletName</portlet-name>
<header-content>
<!-- main calendar program -->
<link rel="stylesheet" type="text/css" media="all" href="/calendar-win2k-cold-1.css"  title="win2k-cold-1"/>
</header-content>
</portlet>
</portlet-app>

Generates an error :
Caused by: org.xml.sax.SAXException: Attribute "title" must be declared for element type "link". @ *unknown*[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 lists.jboss.org  Mon Aug  6 03:43:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 03:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19327501.1186386229764.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1017?page=comments#action_12371179 ] 
            
Galder Zamarreno commented on EJBTHREE-1017:
--------------------------------------------

What link are you refering to when you say that the link 
is not here? If you're refering to the support case link, it is 
already in the JIRA issue.

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 03:45:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 03:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30863256.1186386349449.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1017?page=comments#action_12371180 ] 
            
Galder Zamarreno commented on EJBTHREE-1017:
--------------------------------------------

or you mean to mark the patch as complete?

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 03:55:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 6 Aug 2007 03:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1621) "title"
 attribute of "link" tag in jboss-portlet.xml is unhandled
In-Reply-To: <30538884.1186386229579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28532855.1186386949289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1621?page=all ]

Thomas Heute updated JBPORTAL-1621:
-----------------------------------

          Component/s: Portal Core
        Fix Version/s: 2.6.2 Final
    Affects Version/s: 2.6.1 Final

> "title" attribute of "link" tag in jboss-portlet.xml is unhandled
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-1621
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1621
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>         Environment: JBoss Portal 2.6.1 GA bundled
>            Reporter: Pavel Myshkin
>             Fix For: 2.6.2 Final
>
>
> JBOSS-PORTLET.XML
> --------------------------------
> <!DOCTYPE portlet-app PUBLIC
>    "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
>    "dtd/jboss-portlet_2_6.dtd">
> <portlet-app>
> <portlet>
> <portlet-name>PortletName</portlet-name>
> <header-content>
> <!-- main calendar program -->
> <link rel="stylesheet" type="text/css" media="all" href="/calendar-win2k-cold-1.css"  title="win2k-cold-1"/>
> </header-content>
> </portlet>
> </portlet-app>
> Generates an error :
> Caused by: org.xml.sax.SAXException: Attribute "title" must be declared for element type "link". @ *unknown*[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 lists.jboss.org  Mon Aug  6 04:44:53 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 04:44:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14043696.1186389893765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12371181 ] 
            
Koen Aers commented on GPD-77:
------------------------------

ROTFL

Maybe you need to go into the 7-character acromym space to still find something useful in the workflow/BPM space ;-)

As for the problem at hand. Isn't it possible to do use the XmlAdapter.initialze(SemanticElement) method to override the (default) values that were set in the SemanticElement.initialize() method by the values that are specified in the xml? This method was created for this purpose in any case.

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Mon Aug  6 05:21:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 05:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9444772.1186392109360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-128?page=all ]

Koen Aers resolved GPD-128.
---------------------------

    Resolution: Won't Fix

John, 

I forgot to delete the XmlAdapterRegistry.getConfigurationElementByXmlElementName(String) method while implementing GPD-111. In fact you should now use the XmlAdapterRegistry.getConfigurationElementByXmlNode(Node) to obtain the correct configuration element. You can have multiple configurationelements related to the same xml node name. There are still issues with it, but I am working on fixing those. Have a look at GPD-111 and feel free to ask for clarifications.

Regards,
Koen

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Mon Aug  6 06:08:50 2007
From: jira-events at lists.jboss.org (Holger Szillat (JIRA))
Date: Mon, 6 Aug 2007 06:08:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-429) Support for
 external security systems
Message-ID: <27304829.1186394930152.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-429?page=comments#action_12371186 ] 
            
Holger Szillat commented on JBPM-429:
-------------------------------------

I have made the following changes to my source-code of the jBPM v.3.1.4:

protected Delegation readAssignmentDelegation( Element assignmentElement ) {
    Delegation assignmentDelegation = new Delegation();
    String expression = assignmentElement.attributeValue( "expression" );
    String actorId = assignmentElement.attributeValue( "actor-id" );
    String pooledActors = assignmentElement.attributeValue( "pooled-actors" );
    String assignmentClass = assignmentElement.attributeValue( "class" );

    if ( expression != null ) {
      assignmentDelegation.setProcessDefinition( processDefinition );

      if ( assignmentClass != null )
        assignmentDelegation.setClassName( assignmentClass );
      else
        assignmentDelegation
            .setClassName( "org.jbpm.identity.assignment.ExpressionAssignmentHandler" );

      assignmentDelegation.setConfiguration( "<expression>" + expression
          + "</expression>" );

    } else {
      if ( ( actorId != null ) || ( pooledActors != null ) ) {
        assignmentDelegation.setProcessDefinition( processDefinition );
        assignmentDelegation
            .setClassName( "org.jbpm.taskmgmt.assignment.ActorAssignmentHandler" );
        String configuration = "";
        if ( actorId != null ) {
          configuration += "<actorId>" + actorId + "</actorId>";
        }
        if ( pooledActors != null ) {
          configuration += "<pooledActors>" + pooledActors + "</pooledActors>";
        }
        assignmentDelegation.setConfiguration( configuration );

      } else {
        assignmentDelegation.read( assignmentElement, this );
      }
    }
    return assignmentDelegation;
  }


Note, that I simply read the class-element (which is allowed according to the XML-grammar) and only set the "default" handler if the element was not specified.

Maybe it helps...

> 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 lists.jboss.org  Mon Aug  6 06:35:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 06:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17108692.1186396549330.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371189 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

I made a mistake implementing the priority comparator. I think it should work now, can you verify?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 07:27:03 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 07:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-111) Add ability to
 forward and reverse
 map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29543934.1186399623197.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Koen Aers resolved GPD-111.
---------------------------

    Resolution: Done

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 07:53:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 6 Aug 2007 07:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1020)
	java:comp/EJBContext broken
In-Reply-To: <9377492.1185368221039.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28751618.1186401229326.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1020?page=all ]

Carlo de Wolf resolved EJBTHREE-1020.
-------------------------------------

    Resolution: Done

> java:comp/EJBContext broken
> ---------------------------
>
>                 Key: EJBTHREE-1020
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1020
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> java:comp/EJBContext is bound at semi-random times, which results in broken behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 09:08:59 2007
From: jira-events at lists.jboss.org (Jessica Sant (JIRA))
Date: Mon, 6 Aug 2007 09:08:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8335076.1186405739463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1017?page=all ]

Jessica Sant resolved EJBTHREE-1017.
------------------------------------

    Resolution: Done

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 09:10:49 2007
From: jira-events at lists.jboss.org (Jessica Sant (JIRA))
Date: Mon, 6 Aug 2007 09:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1017) EJBTHREE-863
 Patch for EJB3 RC9 Patch 1
In-Reply-To: <21850611.1185176627079.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <930840.1186405849472.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1017?page=all ]

Jessica Sant updated EJBTHREE-1017:
-----------------------------------

    Patch Repository Link: https://network.jboss.com/jbossnetwork/restricted/softwareDetail.html?softwareId=a0430000007j8N6

> EJBTHREE-863 Patch for EJB3 RC9 Patch 1
> ---------------------------------------
>
>                 Key: EJBTHREE-1017
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1017
>             Project: EJB 3.0
>          Issue Type: Support Patch
>          Components: Clustering
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Galder Zamarreno
>         Assigned To: JBN Patch Team
>         Attachments: jboss-ejb3.jar
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Port patch for EJBTHREE-863 to RC9 Patch 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 lists.jboss.org  Mon Aug  6 09:23:49 2007
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 6 Aug 2007 09:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1061) jsr94 constants
 wrong package
 builder config constant, same name as rulebase config constant
Message-ID: <28549329.1186406629349.JavaMail.jira@cloud.prod.atl2.jboss.com>

jsr94 constants wrong package builder config constant, same name as rulebase config constant
--------------------------------------------------------------------------------------------

                 Key: JBRULES-1061
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1061
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JSR94
    Affects Versions:  4.0.0.GA
            Reporter: Juergen none
         Assigned To: Mark Proctor
            Priority: Minor


org.drools.jsr94.rules.Constants, line 49f:

    /** <code>RuleExecutionSet</code> rulebase config constant. */
    public static final String RES_RULEBASE_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";
    
    /** <code>RuleExecutionSet</code> package builder config constant. */
    public static final String RES_PACKAGEBUILDER_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";    

Packagebuilder config constant is same as rulebase config constant. yields classcast exception if a rulebase config is set:

Caused by: java.lang.ClassCastException: org.drools.RuleBaseConfiguration
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:124)
        at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 10:10:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 6 Aug 2007 10:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23959902.1186409449299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=all ]

Carlo de Wolf reassigned EJBTHREE-1025:
---------------------------------------

    Assignee: Carlo de Wolf

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 10:54:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 10:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-759) Create a set of
 deadlock-detecting unit tests
In-Reply-To: <24324626.1157382703762.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7938961.1186412089504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-759?page=all ]

Galder Zamarreno reassigned JBCACHE-759:
----------------------------------------

    Assignee: Galder Zamarreno  (was: Manik Surtani)

> 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.GA
>            Reporter: Manik Surtani
>         Assigned To: Galder Zamarreno
>             Fix For: 2.1.0.GA
>
>
> 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 lists.jboss.org  Mon Aug  6 12:13:49 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 6 Aug 2007 12:13:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1122) Be able to define
 regions using regular expressions
In-Reply-To: <23692257.1183725292844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25520418.1186416829433.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1122?page=all ]

Galder Zamarreno updated JBCACHE-1122:
--------------------------------------

    Priority: Minor  (was: Major)

> Be able to define regions using regular expressions
> ---------------------------------------------------
>
>                 Key: JBCACHE-1122
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1122
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 3.0.0
>
>
> Particularly useful once we have regions as a top-level construct, with region-specific 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 lists.jboss.org  Mon Aug  6 12:50:49 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 6 Aug 2007 12:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1062) Include
 DefaultSpecificationEntries and DefaultImplementationEntries in jar
 manifests
Message-ID: <28007138.1186419049320.JavaMail.jira@cloud.prod.atl2.jboss.com>

Include DefaultSpecificationEntries and DefaultImplementationEntries in jar manifests
-------------------------------------------------------------------------------------

                 Key: JBRULES-1062
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1062
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
            Priority: Trivial
             Fix For: 4.0.1


See "Is there a method to return running jBoss Rules	version" on user mailing 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 lists.jboss.org  Mon Aug  6 12:54:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Mon, 6 Aug 2007 12:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20166121.1186419289578.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-449?page=comments#action_12371229 ] 
            
Anders Andersen commented on JBAOP-449:
---------------------------------------

As I write in the issue I have tried to seperate the two by space, comma, colon and semi colon.
In all cases it seems as the compiler tries to open the complete-string-argument as a single file, what naturally fails.

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Mon Aug  6 12:54:49 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 6 Aug 2007 12:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1062) Include
 DefaultSpecificationEntries and DefaultImplementationEntries in jar
 manifests
In-Reply-To: <28007138.1186419049320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21028031.1186419289710.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1062?page=all ]

Geoffrey De Smet resolved JBRULES-1062.
---------------------------------------

    Resolution: Done

fixed

> Include DefaultSpecificationEntries and DefaultImplementationEntries in jar manifests
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1062
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1062
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> See "Is there a method to return running jBoss Rules	version" on user mailing 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 lists.jboss.org  Mon Aug  6 13:04:51 2007
From: jira-events at lists.jboss.org (tmullett (JIRA))
Date: Mon, 6 Aug 2007 13:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1033) string_max
 parameterization doesn't work
In-Reply-To: <19022120.1186174849551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27184107.1186419891309.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1033?page=comments#action_12371235 ] 
            
tmullett commented on JBPM-1033:
--------------------------------

I tried it with the hibernate 3.2.3ga that comes with the jbpm-jpdl 3.2.1 download, with the same results. I tried rolling back a little further (3.0.5) but that version complained about some of the named queries.



> string_max parameterization doesn't work 
> -----------------------------------------
>
>                 Key: JBPM-1033
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1033
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: WIndows XP, Hibernate 3.2.4.sp1, Java 1.4.2
>            Reporter: tmullett
>         Assigned To: Tom Baeyens
>
> Fields in the hibernate mapping files declared as type "string_max" should be truncated to the parameterized length. The mapping files do this parameterization with a "length" attribute on the property element. It looks like this (from ActionLog.hbm.xml):
> <property name="exception"
>               type="string_max"
>               column="EXCEPTION_"
>               length="4000" />
> 4000 also happens to be what StringMax will use if it can't find or parse its parameterization. We needed to shorten some fields to fit jBpm into MS SQL Server. When we shortened the length, we noticed that the parameter was being ignored, causing jdbc to blow chunks.  org.jbpm.db.hibernate.StringMax.setParameterValues() always gets a null passed in for it's parameters with this setup. To get it to work , we changed it to 
>     <property name="exception" column="EXCEPTION_">
> 		<type name="string_max">
> 			<param name="length">1000</param>
> 		</type>
>     </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 lists.jboss.org  Mon Aug  6 13:15:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 6 Aug 2007 13:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10048215.1186420549654.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=all ]

Mark Proctor updated JBRULES-1060:
----------------------------------

    Fix Version/s: 4.0.1

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Mon Aug  6 15:33:59 2007
From: jira-events at lists.jboss.org (Jacques Belissent (JIRA))
Date: Mon, 6 Aug 2007 15:33:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-868)
 java.lang.IllegalArgumentException: Unable to find operation XYZ for
 dependent beans in seperate jars
In-Reply-To: <5235901.1170897390091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26902527.1186428839591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-868?page=comments#action_12371241 ] 
            
Jacques Belissent commented on EJBTHREE-868:
--------------------------------------------

I think I am hitting this bug.  

Is there a workaround other than upgrading

> java.lang.IllegalArgumentException: Unable to find operation XYZ for dependent beans in seperate jars
> -----------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-868
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-868
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.0 GA
>
>
> java.lang.IllegalArgumentException: Unable to find operation sayHello()
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
> 	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
> 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
> 	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:263)
> 	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:999)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:454)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261)
> Caused by: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:231)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy89.sayHello(Unknown Source)
> 	at org.jboss.ejb3.test.dependency.ABean.getHelloB(ABean.java:18)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 15:53:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 15:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14291104.1186430029408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers reopened GPD-78:
--------------------------

             
reopening because of http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115265&start=0&postdays=postDays&postorder=postOrder&highlight=highlight

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Mon Aug  6 15:55:58 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Aug 2007 15:55:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23791579.1186430158663.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers updated GPD-78:
-------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115265&start=0&postdays=postDays&postorder=postOrder&highlight=highlight
        Affects Version/s: jBPM JPDL Designer 3.1.0.beta2
                               (was: jBPM JPDL Designer 3.1.0.alpha4)

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Mon Aug  6 15:59:49 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Mon, 6 Aug 2007 15:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1051) Guided Editor
 does not remmeber the folder location for new editors
In-Reply-To: <9802279.1185911089373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30146865.1186430389313.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1051?page=all ]

Ahti Kitsik resolved JBRULES-1051.
----------------------------------

    Resolution: Done
      Assignee: Mark Proctor  (was: Ahti Kitsik)

new file wizard/dialog fixed.

> Guided Editor does not remmeber the folder location for new editors
> -------------------------------------------------------------------
>
>                 Key: JBRULES-1051
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1051
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> The guided editor should remember the target folder when being 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 lists.jboss.org  Mon Aug  6 16:17:07 2007
From: jira-events at lists.jboss.org (Niall P (JIRA))
Date: Mon, 6 Aug 2007 16:17:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <6214910.1186431427591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12371246 ] 
            
Niall P commented on JBAS-2299:
-------------------------------

BeanUtils 1.8.0 Beta has been released for testing.

See http://www.apachenews.org/archives/001045.html

Would be good if you could test whether this issue has been resolved before the final 1.8.0 release

Niall

> 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.2.2.GA
>
>         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 lists.jboss.org  Mon Aug  6 16:39:57 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Aug 2007 16: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: <23729028.1186432797846.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Attachment: Sampleapp.zip

> 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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Mon Aug  6 16:43:49 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Mon, 6 Aug 2007 16:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
Message-ID: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>

ConfigInfoElementDomAdapter doesnt define node types
----------------------------------------------------

                 Key: GPD-129
                 URL: http://jira.jboss.com/jira/browse/GPD-129
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:

<?xml version="1.0"?>

<process-definition name="Movie" version="11">
<start-state name="Start">
<transition to="Get MPEG Properties" />
	</start-state>
<node name="Get MPEG Properties">
			<action class="SomeActionHandler"><send>010901</send>
<keys>
		<entry>
                                            <key>VarName</key>
                                            <value>1122</value>
                                </entry>
	</keys>
	<receive>
		<element>030101</element>
		<element>030102</element>	
	</receive>
</action>
				<transition to="End"/>	</node>
<end-state name="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 lists.jboss.org  Mon Aug  6 16:47:49 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Mon, 6 Aug 2007 16:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-130) Class Cast exception in
 ConfigInfoElement.getConfigInfoElements()
Message-ID: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>

Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
------------------------------------------------------------------

                 Key: GPD-130
                 URL: http://jira.jboss.com/jira/browse/GPD-130
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 16:50:04 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Mon, 6 Aug 2007 16:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-131)
 XmlAdapter.getTextContent() appends null
Message-ID: <7479123.1186433404059.JavaMail.jira@cloud.prod.atl2.jboss.com>

XmlAdapter.getTextContent() appends null
----------------------------------------

                 Key: GPD-131
                 URL: http://jira.jboss.com/jira/browse/GPD-131
             Project: JBoss jBPM GPD
          Issue Type: Bug
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


the getTextContent() method in XmlAdapter class. There should be a null check while getting the node value (this issue also comes up when you have nested configInfoElements). So the following method in XmlAdapter.java : 


protected String getTextContent() {
		StringBuffer buffer = new StringBuffer();
		NodeList list = getNode().getChildNodes();
		for (int i = 0; i < list.getLength(); i++) {
			buffer.append(list.item(i).getNodeValue());
		}
		return buffer.toString().trim();
	}
	 

should be changed to: 


protected String getTextContent() {
		StringBuffer buffer = new StringBuffer();
		NodeList list = getNode().getChildNodes();
		for (int i = 0; i < list.getLength(); i++) {
			String nodeValue = list.item(i).getNodeValue();
			if (nodeValue != null)
				buffer.append(nodeValue);
		}
		return buffer.toString().trim();
	}
	 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 16:55:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 6 Aug 2007 16:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-360) Retrotranslated
 project dependencies
In-Reply-To: <24574832.1177365880415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26934210.1186433749308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-360?page=all ]

Paul Gier closed JBBUILD-360.
-----------------------------

    Resolution: Done

A projects dependencies can now be retro-translated and then either installed to a local repo or deployed to a remote repo.

> Retrotranslated project dependencies
> ------------------------------------
>
>                 Key: JBBUILD-360
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-360
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-retro-plugin
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-retro-plugin-1.0
>
>
> The jboss-retro plugin should be able to translated a project's dependency jars along with the main project artifact.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 17:14:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 6 Aug 2007 17:14:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1051) Guided Editor
 does not remmeber the folder location for new editors
In-Reply-To: <9802279.1185911089373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4493983.1186434890357.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1051?page=all ]

Mark Proctor updated JBRULES-1051:
----------------------------------

    Assignee: Ahti Kitsik  (was: Mark Proctor)

> Guided Editor does not remmeber the folder location for new editors
> -------------------------------------------------------------------
>
>                 Key: JBRULES-1051
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1051
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> The guided editor should remember the target folder when being 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 lists.jboss.org  Mon Aug  6 17:24:49 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Mon, 6 Aug 2007 17:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
Message-ID: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>

Leak in org/jboss/mx/loading/UnifiedClassLoader3
------------------------------------------------

                 Key: JBAS-4593
                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ClassLoading
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Mike Millson
         Assigned To: Scott M Stark


[description pasted from support case]

After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.amfam" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:

found a path to the target: 26093 (depth: 5)
0 0 Heap root
26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
160611 0 Instance: [Ljava/lang/Object;
161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
217357 0 Instance: Ljavax/management/Notification;
26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;

So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.

Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 18:03:49 2007
From: jira-events at lists.jboss.org (Rajesh Rajasekaran (JIRA))
Date: Mon, 6 Aug 2007 18:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1160)
 org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
Message-ID: <19125763.1186437829351.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
-------------------------------------------------------------------------

                 Key: JBCACHE-1160
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1160
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Rajesh Rajasekaran
         Assigned To: Jason T. Greene


http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/20070806045019/results/org/jboss/cache/pojo/rollback/InMemoryTxUndoTest(tcp).html

The test attaches a second Person object to an existing node (Person object) within the scope of a transaction and rolls back.
The following exception occurs when trying to retrieve the first object.

testSimpleTxWithRollback3	
Error	org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4

org.jboss.cache.pojo.PojoCacheAlreadyDetachedException: org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4 at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.verifyAttached(CacheFieldInterceptor.java:177) at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.invoke(CacheFieldInterceptor.java:153) at org.jboss.cache.pojo.test.Person$age_Get.invokeNext(Person$age_Get.java) at org.jboss.cache.pojo.test.Person.age_r_$aop(Person.java) at org.jboss.cache.pojo.test.Person.getAge(Person.java:76) at org.jboss.cache.pojo.rollback.InMemoryTxUndoTest.testSimpleTxWithRollback3(InMemoryTxUndoTest.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 18:08:49 2007
From: jira-events at lists.jboss.org (Rajesh Rajasekaran (JIRA))
Date: Mon, 6 Aug 2007 18:08:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1161) PojoCache
 loadtime example failure
Message-ID: <17873568.1186438129330.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache loadtime example failure
----------------------------------

                 Key: JBCACHE-1161
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1161
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Rajesh Rajasekaran
         Assigned To: Jason T. Greene


The following exceptions occurs when running the example under JBossCache-pojo-2.0.0.GA\examples\PojoCache\loadtime
"build.bat compile" &  "build.bat run.loadtime.example"

     [java] Exception in thread "main" java.lang.IllegalArgumentException: PojoCache.putObject(): Object type is neither  aspectized nor Serializable nor an array of prim
itives. Object class name is examples.Student
     [java]     at org.jboss.cache.pojo.util.AopUtil.checkObjectType(AopUtil.java:125)
     [java]     at org.jboss.cache.pojo.interceptors.CheckNonSerializableInterceptor.invoke(CheckNonSerializableInterceptor.java:36)
     [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
     [java]     at org.jboss.cache.pojo.interceptors.CheckIdInterceptor.invoke(CheckIdInterceptor.java:33)
     [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
     [java]     at org.jboss.cache.pojo.interceptors.PojoBeginInterceptor.invoke(PojoBeginInterceptor.java:36)
     [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
     [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
     [java]     at test.examples.StudentMaintTest.testPropagation(StudentMaintTest.java:99)
     [java]     at test.examples.StudentMaintTest.main(StudentMaintTest.java:145)
     [java] Java Result: 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 lists.jboss.org  Mon Aug  6 20:22:49 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 6 Aug 2007 20:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1063) Failing location
 determination tests
Message-ID: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>

Failing location determination tests
------------------------------------

                 Key: JBRULES-1063
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 4.0.1
            Reporter: Philippe Ombredanne
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  

Their name is prefixed with FAILING

I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug  6 21:29:51 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Aug 2007 21:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <5407486.1186450191138.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12371261 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

started a discussion on Apache:

https://issues.apache.org/jira/browse/BEANUTILS-291

> 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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Tue Aug  7 00:01:21 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Aug 2007 00:01:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4594) Fix JBossMessaging
	testcases
Message-ID: <29262583.1186459281761.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix JBossMessaging testcases
----------------------------

                 Key: JBAS-4594
                 URL: http://jira.jboss.com/jira/browse/JBAS-4594
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For:  JBossAS-5.0.0.Beta3


I created a task just to associate my commits while fixing the JBossMessaging/generic JMS 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 lists.jboss.org  Tue Aug  7 00:07:05 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Aug 2007 00:07:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4585) System Properties
 not being parsed on MBeans
In-Reply-To: <23803324.1185569447124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4642889.1186459625563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4585?page=all ]

Clebert Suconic updated JBAS-4585:
----------------------------------

    Summary: System Properties not being parsed on MBeans  (was: Properties not being correctly parsed on JCA)

> System Properties not being parsed on MBeans
> --------------------------------------------
>
>                 Key: JBAS-4585
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4585
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  JBossAS-5.0.0.Beta3
>            Reporter: Clebert Suconic
>         Assigned To: Scott M Stark
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 02:15:49 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 02:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-116) Validation of
 paths on case insensative file systems
In-Reply-To: <22397393.1165080415856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21001710.1186467349414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-116?page=all ]

Scott M Stark updated JBMICROCONT-116:
--------------------------------------

    Fix Version/s: JBossMC-2.0.0.CR1
                       (was: JBossMC-2.0.0.Beta4)

> Validation of paths on case insensative file systems
> ----------------------------------------------------
>
>                 Key: JBMICROCONT-116
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-116
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: VFS
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>            Priority: Critical
>             Fix For: JBossMC-2.0.0.CR1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Remy brought up the issue of being able to validate whether a given url mapping is valid when case insensative file systems are in use. See the forum reference for the details.
> We should be able to configure the VFS file context to allow for case sensative finds when the underlying file system is not case sensative.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 02:47:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 02:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4595) Inconclusive
 exception thrown by HttpNamingContextFactory
Message-ID: <28863406.1186469269372.JavaMail.jira@cloud.prod.atl2.jboss.com>

Inconclusive exception thrown by HttpNamingContextFactory
---------------------------------------------------------

                 Key: JBAS-4595
                 URL: http://jira.jboss.com/jira/browse/JBAS-4595
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.1.GA
         Environment: Hudson only
Sun VM 1.5.0_12-b04
Ubuntu 6.06
            Reporter: Carlo de Wolf
            Priority: Minor
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


javax.naming.NamingException: Failed to retrieve Naming interface [Root exception is java.net.ConnectException: Connection refused]
	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:84)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
	at javax.naming.InitialContext.init(InitialContext.java:223)
	at javax.naming.InitialContext.<init>(InitialContext.java:197)
	at org.jboss.ejb3.test.invoker.unit.InvokerTestCase.testHttp(InvokerTestCase.java:55)
	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.net.ConnectException: Connection refused
	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
	at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1223)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1217)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906)
	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:133)
	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:80)
	... 26 more
Caused by: java.net.ConnectException: Connection refused
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
	at java.net.Socket.connect(Socket.java:519)
	at java.net.Socket.connect(Socket.java:469)
	at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
	at sun.net.www.http.HttpClient.New(HttpClient.java:304)
	at sun.net.www.http.HttpClient.New(HttpClient.java:316)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:813)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:765)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:690)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934)
	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1903)
	at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:573)
	at java.net.URLConnection.getContentLength(URLConnection.java:468)
	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:128)
	... 27 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 lists.jboss.org  Tue Aug  7 02:47:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 02:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4595) Inconclusive
 exception thrown by HttpNamingContextFactory
In-Reply-To: <28863406.1186469269372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22488859.1186469269517.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4595?page=all ]

Carlo de Wolf reassigned JBAS-4595:
-----------------------------------

    Assignee: Carlo de Wolf

> Inconclusive exception thrown by HttpNamingContextFactory
> ---------------------------------------------------------
>
>                 Key: JBAS-4595
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4595
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>         Environment: Hudson only
> Sun VM 1.5.0_12-b04
> Ubuntu 6.06
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Minor
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> javax.naming.NamingException: Failed to retrieve Naming interface [Root exception is java.net.ConnectException: Connection refused]
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:84)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
> 	at javax.naming.InitialContext.init(InitialContext.java:223)
> 	at javax.naming.InitialContext.<init>(InitialContext.java:197)
> 	at org.jboss.ejb3.test.invoker.unit.InvokerTestCase.testHttp(InvokerTestCase.java:55)
> 	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.net.ConnectException: Connection refused
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> 	at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1223)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1217)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:133)
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:80)
> 	... 26 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> 	at java.net.Socket.connect(Socket.java:519)
> 	at java.net.Socket.connect(Socket.java:469)
> 	at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:304)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:316)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:813)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:765)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:690)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934)
> 	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1903)
> 	at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:573)
> 	at java.net.URLConnection.getContentLength(URLConnection.java:468)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:128)
> 	... 27 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 lists.jboss.org  Tue Aug  7 03:00:49 2007
From: jira-events at lists.jboss.org (Dr. Gernot Starke (JIRA))
Date: Tue, 7 Aug 2007 03:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1064) "->" notation for
 predicates missing in documentation
Message-ID: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>

"->" notation for predicates missing in documentation
-----------------------------------------------------

                 Key: JBRULES-1064
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.GA
            Reporter: Dr. Gernot Starke
         Assigned To: Mark Proctor
            Priority: Minor


the notation "->" for adressing complex terms is missing from 4.0.0 documentation.

It has been "return value operator" in 3.0.6:

<quoted from 3.0.6>
Example 3.13. Return Value operator

Person( girlAge : age, sex = "F" )
Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
</quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 03:31:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 03:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4595) Inconclusive
 exception thrown by HttpNamingContextFactory
In-Reply-To: <28863406.1186469269372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31016707.1186471909405.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4595?page=all ]

Carlo de Wolf resolved JBAS-4595.
---------------------------------

    Resolution: Done

> Inconclusive exception thrown by HttpNamingContextFactory
> ---------------------------------------------------------
>
>                 Key: JBAS-4595
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4595
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>         Environment: Hudson only
> Sun VM 1.5.0_12-b04
> Ubuntu 6.06
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Minor
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> javax.naming.NamingException: Failed to retrieve Naming interface [Root exception is java.net.ConnectException: Connection refused]
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:84)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
> 	at javax.naming.InitialContext.init(InitialContext.java:223)
> 	at javax.naming.InitialContext.<init>(InitialContext.java:197)
> 	at org.jboss.ejb3.test.invoker.unit.InvokerTestCase.testHttp(InvokerTestCase.java:55)
> 	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.net.ConnectException: Connection refused
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> 	at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1223)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1217)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:133)
> 	at org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:80)
> 	... 26 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> 	at java.net.Socket.connect(Socket.java:519)
> 	at java.net.Socket.connect(Socket.java:469)
> 	at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:304)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:316)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:813)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:765)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:690)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934)
> 	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1903)
> 	at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:573)
> 	at java.net.URLConnection.getContentLength(URLConnection.java:468)
> 	at org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:128)
> 	... 27 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 lists.jboss.org  Tue Aug  7 03:33:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 7 Aug 2007 03:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1026) Refactor
 extended persistence context
Message-ID: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor extended persistence context
-------------------------------------

                 Key: EJBTHREE-1026
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1026
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf
             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Tue Aug  7 05:03:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-132) random duedate
 attributes appear on task elements
Message-ID: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>

random duedate attributes appear on task elements
-------------------------------------------------

                 Key: GPD-132
                 URL: http://jira.jboss.com/jira/browse/GPD-132
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: osx, macbook pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Minor


while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:08:26 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:08:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
Message-ID: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>

with two transitions from a node, both need to be labelled, or jbpm-console exceptions
--------------------------------------------------------------------------------------

                 Key: GPD-133
                 URL: http://jira.jboss.com/jira/browse/GPD-133
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: osx, macbook pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers


when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:10:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-134) form file names
 generated from the task dialogue are unstable
Message-ID: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>

form file names generated from the task dialogue are unstable
-------------------------------------------------------------

                 Key: GPD-134
                 URL: http://jira.jboss.com/jira/browse/GPD-134
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: osx macbook pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Minor


the form names generated from the task dialogue are sensitive to content...

'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console

the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:12:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:12:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7755449.1186477969363.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Component/s: jpdl

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19436343.1186478209520.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-132?page=comments#action_12371283 ] 
            
Koen Aers commented on GPD-132:
-------------------------------

Ross,

AFAIR duedate is a mandatory attribute on some elements. What elements are you talking about?

Regards,
Koen

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:19:14 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:19:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3146099.1186478354838.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371285 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

Can you provide an example of this situation? A minimal processdefinition and the accompanying task form that produces the problem e.g.

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:19:14 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:19:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17773892.1186478354965.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371286 ] 
            
Koen Aers commented on GPD-134:
-------------------------------

Do you have any indication about database specificity? What DB are you using?

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:30:32 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 05:30:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-135) bendpoints are not
 properly drawn when reading a processdefinition from disk
Message-ID: <18689252.1186479032370.JavaMail.jira@cloud.prod.atl2.jboss.com>

bendpoints are not properly drawn when reading a processdefinition from disk
----------------------------------------------------------------------------

                 Key: GPD-135
                 URL: http://jira.jboss.com/jira/browse/GPD-135
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Koen Aers
         Assigned To: Koen Aers
             Fix For: jBPM JPDL Designer 3.1.0.CR




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:30:32 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:30:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18367646.1186479032539.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-132?page=comments#action_12371290 ] 
            
Ross McDonald commented on GPD-132:
-----------------------------------

Hi,

apologies, the duedate attributes appear on task elements, generated somehow from the Tasks > Details dialogue, although I am not attempting to specify a duedate, as their is no duedate for the task, this is occurring infrequently,

cheers

Ross

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:32:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5811580.1186479169361.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371291 ] 
            
Ross McDonald commented on GPD-134:
-----------------------------------

Hi,

sure sorry, was reporting all of these issues in a hurry before a demo to the boss :-)

I am using Mysql 5.0.37, can provide hibernate connection into and config if required,

cheers

Ross

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:34:49 2007
From: jira-events at lists.jboss.org (Felipe (JIRA))
Date: Tue, 7 Aug 2007 05:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-272) allow xpath
 expression/query to create more than one occurrence of an element
In-Reply-To: <21460509.1185436907082.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9300617.1186479289300.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-272?page=comments#action_12371292 ] 
            
Felipe commented on BPEL-272:
-----------------------------

WORKAROUND UNTIL THIS IS FIXED:

Following the oracle approach (cf. supra.), a web service can be used to provide an operation that returns an array of the right size. Operations to add items can be done too. Z.B. creating a lista of size four:

ESQUEMA:
   <complexType name="ListaString">
     <sequence>
       <element name="item" type="xsd:string" minOccurs="1" maxOccurs="unbounded"></element>
     </sequence>
   </complexType>
WSDL:
   <wsdl:message name="obtenerListaStringRequest">
   	<wsdl:part name="obtenerListaStringRequest" type="xsd:int"></wsdl:part>
   </wsdl:message>
   <wsdl:message name="obtenerListaStringResponse">
   	<wsdl:part name="obtenerListaStringReturn"
   		type="tns1:ListaString">
   	</wsdl:part>
   </wsdl:message>
      <wsdl:operation name="obtenerListaString">
      	<wsdl:documentation>Este m?todo fue a?adido para corregir las deficiencias del bpel en la creaci?n de secuencias. Cf. http://jira.jboss.com/jira/browse/BPEL-272</wsdl:documentation>
      	<wsdl:input message="impl:obtenerListaStringRequest" name="listaStringPedir"></wsdl:input>
      	<wsdl:output message="impl:obtenerListaStringResponse" name="listaStringDevolver"></wsdl:output>
      </wsdl:operation>
BPEL:
<variable name="listacadenas" messageType="BAncha:obtenerListaStringResponse" />
    <variable name="entero" messageType="BAncha:obtenerListaStringRequest"/>
<assign>
  	<copy>
  		<from expression="4"/>
  		<to variable="entero" part="obtenerListaStringRequest"/>
  	</copy>
  </assign>
    <invoke partnerLink="BaPartnerLink" portType="BA:Bara"
              operation="obtenerListaString" inputVariable="entero"
              outputVariable="listacadenas"/>

  Haleeee

> allow xpath expression/query to create more than one occurrence of an element
> -----------------------------------------------------------------------------
>
>                 Key: BPEL-272
>                 URL: http://jira.jboss.com/jira/browse/BPEL-272
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The current XPath sublanguage implementation automatically creates nodes missing from location paths during assignment. This facility has a number of conceptual limitations. One of them is the inability to append a child element to an existing element if the latter already has a child element with the same name. There is no XPath syntax to express that a new element is required!
> It is tempting to think of a numeric XPath predicate as an array index, leading to the next snippet:
> <copy>
>  <from><literal>haha</literal></from>
>  <to variable='laughter' xmlns:ex='http://jbpm.org/bpel/examples'>
>   <query>ex:laugh[last() + 1]</query>
>  </to>
> </copy>
> However, such an interpretation of a predicate is wrong. Consider the following extract from XPath 1.0 specification on predicates:
> "A PredicateExpr is evaluated by evaluating the Expr and converting the result to a boolean. If the result is a number, the result will be converted to true if the number is equal to the context position and will be converted to false otherwise."
> The description of the last() function reads:
> "The last function returns a number equal to the context size from the expression evaluation context."
> Noticed the problem? The context position is never greater than the context size. Therefore the predicate [last() + 1] does not represent the position "one past the context size" but the boolean value false. Unfortunately, no other predicate seems appropriate. 
> PROPOSAL Introduce a minor deviation from the XPath 1.0 specification. Interpret the result of a numeric predicate that equals the context size plus one as a  request to create a new occurrence of the 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 lists.jboss.org  Tue Aug  7 05:59:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28640634.1186480789466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371294 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

Hi, sure, attached is the original process definition, the exception, and then the fixed definition, btw, I am running this whole thing on tomcat 5.0.28, and once this exception occurrs, the tasks view seems to be broken for good, even when I end the process, I can provide more info if needed,

cheers

Ross



> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:59:49 2007
From: jira-events at lists.jboss.org (Jiri Pechanec (JIRA))
Date: Tue, 7 Aug 2007 05:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1034) DB test suites are
	not operationg
Message-ID: <2673921.1186480789623.JavaMail.jira@cloud.prod.atl2.jboss.com>

DB test suites are not operationg
---------------------------------

                 Key: JBPM-1034
                 URL: http://jira.jboss.com/jira/browse/JBPM-1034
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
         Environment: Hudson QE
            Reporter: Jiri Pechanec
         Assigned To: Tom Baeyens


The database related test cases are failing due to Hibernate misconfiguration. Either the wrong property file is read or the value inside are incorrect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:59:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23505372.1186480789783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Attachment: broken_process.xml

the broken example process

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 05:59:50 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 05:59:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30653993.1186480790016.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Attachment: broken_process_exception.txt

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:01:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 06:01:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25511451.1186480909395.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Attachment: fixed_process.xml

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:01:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 7 Aug 2007 06:01:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14828339.1186480909579.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Ross McDonald updated GPD-133:
------------------------------

    Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28  (was: osx, macbook pro, eclipse 3.3.0)

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:43:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
In-Reply-To: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32355651.1186483429540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-129?page=all ]

Koen Aers updated GPD-129:
--------------------------

      Component/s: jpdl
    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> ConfigInfoElementDomAdapter doesnt define node types
> ----------------------------------------------------
>
>                 Key: GPD-129
>                 URL: http://jira.jboss.com/jira/browse/GPD-129
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:
> <?xml version="1.0"?>
> <process-definition name="Movie" version="11">
> <start-state name="Start">
> <transition to="Get MPEG Properties" />
> 	</start-state>
> <node name="Get MPEG Properties">
> 			<action class="SomeActionHandler"><send>010901</send>
> <keys>
> 		<entry>
>                                             <key>VarName</key>
>                                             <value>1122</value>
>                                 </entry>
> 	</keys>
> 	<receive>
> 		<element>030101</element>
> 		<element>030102</element>	
> 	</receive>
> </action>
> 				<transition to="End"/>	</node>
> <end-state name="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 lists.jboss.org  Tue Aug  7 06:43:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-130) Class Cast exception in
 ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4968845.1186483429661.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-130?page=all ]

Koen Aers updated GPD-130:
--------------------------

      Component/s: jpdl
    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:45:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-131)
 XmlAdapter.getTextContent() appends null
In-Reply-To: <7479123.1186433404059.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7423678.1186483549455.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-131?page=all ]

Koen Aers updated GPD-131:
--------------------------

          Component/s: jpdl
        Fix Version/s: jBPM JPDL Designer 3.1.0.CR
    Affects Version/s: jBPM JPDL Designer 3.1.0.beta2

> XmlAdapter.getTextContent() appends null
> ----------------------------------------
>
>                 Key: GPD-131
>                 URL: http://jira.jboss.com/jira/browse/GPD-131
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> the getTextContent() method in XmlAdapter class. There should be a null check while getting the node value (this issue also comes up when you have nested configInfoElements). So the following method in XmlAdapter.java : 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			buffer.append(list.item(i).getNodeValue());
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 
> should be changed to: 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			String nodeValue = list.item(i).getNodeValue();
> 			if (nodeValue != null)
> 				buffer.append(nodeValue);
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:45:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33400397.1186483549615.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-132?page=all ]

Koen Aers updated GPD-132:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:47:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27195101.1186483669289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Koen Aers updated GPD-133:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.CR

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:49:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17233717.1186483789296.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371299 ] 
            
Koen Aers commented on GPD-134:
-------------------------------

Could you reproduce this on HSQLDB as well? Anyway, this seems to me like a plain jBPM bug which has probably nothing to do with the GPD. Maybe we should move this to the jBPM project.

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:51:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:51:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-39) Adapt property sheet
 according to context in xml tab
In-Reply-To: <31483791.1168964513032.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1070617.1186483909718.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-39?page=all ]

Koen Aers updated GPD-39:
-------------------------

    Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)

> Adapt property sheet according to context in xml tab
> ----------------------------------------------------
>
>                 Key: GPD-39
>                 URL: http://jira.jboss.com/jira/browse/GPD-39
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> Currently the property sheet does not reflect the context when editing the process definition in the xml source tab.
> Solution : define a selection listener that activates the model object corresponding to the cursor location in the xml source tab.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:51:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:51:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-54) Label and name support
 for graph elements
In-Reply-To: <17703731.1170780140362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11885376.1186483910163.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-54?page=all ]

Koen Aers updated GPD-54:
-------------------------

    Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)

> Label and name support for graph elements
> -----------------------------------------
>
>                 Key: GPD-54
>                 URL: http://jira.jboss.com/jira/browse/GPD-54
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:51:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:51:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-31) Make sure all tasks in
 a process definition have a unique name
In-Reply-To: <27583187.1168958633498.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31493502.1186483910246.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-31?page=all ]

Koen Aers updated GPD-31:
-------------------------

    Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)

> Make sure all tasks in a process definition have a unique name
> --------------------------------------------------------------
>
>                 Key: GPD-31
>                 URL: http://jira.jboss.com/jira/browse/GPD-31
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> When retrieving all tasks from a process definition like so:
>         processDefinition.getTaskMgmtDefinition().getTasks() 
> it returns a MAP of tasks, keyed by task name. This is a problem if two tasks anywhere in the same process definition have the same name.
> By default, the GPD creates all tasks as "task1" when it is the first task on a task node. If none of these were renamed, you would only get a single task when trying to get all of them for the 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 lists.jboss.org  Tue Aug  7 06:53:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 06:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-20) refactor naming strategy
In-Reply-To: <32621900.1168954252939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18049592.1186484029301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-20?page=all ]

Koen Aers updated GPD-20:
-------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0 alpha1)

> refactor naming strategy
> ------------------------
>
>                 Key: GPD-20
>                 URL: http://jira.jboss.com/jira/browse/GPD-20
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> 1) generate default node names when nodes are created: {node1, node2, ...}. use this naming strategy for each node type.
> 2) do not generate a node name for the start-state. users should be able to give the start-state a name, though.
> 3) use the following naming strategy for end states: {end, end2, end3, end4, ...}
> 4) do not generate names for transitions. the problem reporting should generate warnings if a node-type requires named nodes. the correlation between the graphical information and the processdefinition.xml will be done based on the position (index), rather then on the name.
> 5) disallow slashes in names in a process definition (nodes, transitions, process definition, actions, ...) Because slashes will be used as a separator in hierarchical names. We should also investigate if it would be useful to specify a strict set of chars that can be used like e.g. 0-9,a-z,A-Z,space,dot

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 06:58:08 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 06:58:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23863091.1186484288301.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371301 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Is it by intention, that the default priority is MAXINT, if you do not set a value for "mapperClassPriority"?
Because of that, it is not possible to activate a mapping on an existing xml types, since the existing semantic element is always first in the SortedSet.
So I have to set mapperClassPriority for this existing xml mapping.
Or am I missing something?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 07:09:49 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 07:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-136) Widget is disposed in
 Task Controller Variables Table
Message-ID: <24052817.1186484989796.JavaMail.jira@cloud.prod.atl2.jboss.com>

Widget is disposed in Task Controller Variables Table
-----------------------------------------------------

                 Key: GPD-136
                 URL: http://jira.jboss.com/jira/browse/GPD-136
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: Eclipse 3.2.2 on Windows 2000
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


Select a Task Node. Go to Properties View.
Select Tasks:<task>:Controller (default).
Add two variables, remove the second.
Error Log view contains the following SWT Exception:
org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.swt.SWT.error(SWT.java:3374)
	at org.eclipse.swt.SWT.error(SWT.java:3297)
	at org.eclipse.swt.SWT.error(SWT.java:3268)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:435)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:330)
	at org.eclipse.swt.widgets.Control.setVisible(Control.java:2642)
	at org.jbpm.gd.jpdl.util.VariableTableItemWrapper.applyName(VariableTableItemWrapper.java:164)
	at org.jbpm.gd.jpdl.util.VariableTableItemWrapper.cancelEditing(VariableTableItemWrapper.java:150)
	at org.jbpm.gd.jpdl.util.VariableTableCellClickedResolver.mouseDown(VariableTableCellClickedResolver.java:25)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:133)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1930)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:422)
	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)
After that, table input is not working anymore ("Mapped Name" column not editable anymore, 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 lists.jboss.org  Tue Aug  7 08:00:52 2007
From: jira-events at lists.jboss.org (Takayuki Kaneko (JIRA))
Date: Tue, 7 Aug 2007 08:00:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4590) Add new parameter of
 jnp for connecting each time.
In-Reply-To: <28892709.1186042971102.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21463105.1186488052934.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4590?page=all ]

Takayuki Kaneko updated JBAS-4590:
----------------------------------

        Fix Version/s: JBossAS-4.2.2.GA
                       JBossAS-4.0.5.SP1 
    Affects Version/s: JBossAS-4.2.1.GA
                       JBossAS-4.0.5.GA

> Add new parameter of jnp for connecting each time.
> --------------------------------------------------
>
>                 Key: JBAS-4590
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4590
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA
>            Reporter: Takayuki Kaneko
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.SP1 , JBossAS-4.2.2.GA
>
>         Attachments: patch.txt
>
>
> I want to add a new parameter on org.jnp.interfaces.NamingContext for connecting 1099 port each time.
> Our system needs to connect JNDI each time because there is a load balancer between EJB clients and JBoss servers.
> Of course I know the caching server stubs is needed to improve the performance. Our issue might be minority.
> So I made a patch that wouldn't change the default behavior about caching.
> Could you consider the possibilities of applying this patch? We want to use JBoss Application Server on our system.
> 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 lists.jboss.org  Tue Aug  7 08:00:53 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 08:00:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32840182.1186488053264.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371313 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

The value MAX_VALUE was originally chosen because this would be the lowest priority (huh?).

The (second) mistake was that I assumed wrongly the wrong order within the sorted set. 

I think it would indeed be best to do as you suggest and assume MIN_VALUE for the default priority and let contributors specify higher priorities if they want their mapper to take over. If I am not mistaken, the ordering should be from high to low now with the latest commit. Can anyone verify?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 08:10:49 2007
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 7 Aug 2007 08:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4596) Provide
 web-jsptaglibrary_2_1.xsd in $JBOSS_HOME/docs/schema
Message-ID: <17317840.1186488649656.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide web-jsptaglibrary_2_1.xsd in $JBOSS_HOME/docs/schema
------------------------------------------------------------

                 Key: JBAS-4596
                 URL: http://jira.jboss.com/jira/browse/JBAS-4596
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.2.GA
            Reporter: Juergen Zimmermann


When implementing custom TLD files then it makes sense to use the ANT task <schemavalidate> to validate the .tld file. Therefore,  web-jsptaglibrary_2_1.xsd should be provided in $JBOSS_HOME/docs/schema.

BTW, web-jsptaglibrary_2_0.xsd is already in $JBOSS_HOME/docs/schema

web-jsptaglibrary_2_1.xsd is contained in server/default/lib/jsp-api.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 lists.jboss.org  Tue Aug  7 08:20:49 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 08:20:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7061661.1186489249365.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371314 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

I would choose 0 as default, because with extreme values you have easily an overflow in the comparator calculation.
Your change had no impact in my use case. I have chose priority 1 for my mapping.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 08:26:49 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 08:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12169841.1186489609343.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371315 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Now it's clear.
Before your change it was: MAX -1 > 0
After your change it was MIN -1 > 0 because of overflow
   

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 08:57:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 08:57:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <577290.1186491469308.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371317 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Okay, this makes a lot of sense... 0 it will be ;-)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:05:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16521886.1186491949289.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371318 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

It is changed to 0 now. Please check again (but allow half an hour time for the public cvs to synchronize)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:14:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-81) Add support for
 reconnecting transitions
In-Reply-To: <898355.1178879092359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8099900.1186492489599.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-81?page=all ]

Koen Aers updated GPD-81:
-------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.alpha4)

> Add support for reconnecting transitions
> ----------------------------------------
>
>                 Key: GPD-81
>                 URL: http://jira.jboss.com/jira/browse/GPD-81
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: Clean eclipse 3.2.2 and gpd 3.1alpha4
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>
> Not being able to reconnect transitions graphically from e.g. node a to node b is still a big omission for the gpd to be used by 'grey suites' as well as 'jeans and t-shirts', at least within our company. I thought there was a long standing issue for this, but I cannot find it. 
> If someone could point me to a place to start looking into this, I'd be happy to try to implement this (but it will be the only gpd thing I 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 lists.jboss.org  Tue Aug  7 09:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-100) review the delegation
 configuration form
In-Reply-To: <9679061.1182417596922.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <699372.1186492609421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-100?page=all ]

Koen Aers updated GPD-100:
--------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.alpha4)

> review the delegation configuration form
> ----------------------------------------
>
>                 Key: GPD-100
>                 URL: http://jira.jboss.com/jira/browse/GPD-100
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> - have a look at the visibility of the text and table in the configuration form
> - try to fix the resize problem

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:16:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-109) review task form
	generation dialog
In-Reply-To: <22119502.1182883917540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1086988.1186492609514.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-109?page=all ]

Koen Aers updated GPD-109:
--------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.beta1)

> review task form generation dialog
> ----------------------------------
>
>                 Key: GPD-109
>                 URL: http://jira.jboss.com/jira/browse/GPD-109
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> implement focuslost behaviour

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:18:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
In-Reply-To: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19404069.1186492729292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-129?page=all ]

Koen Aers resolved GPD-129.
---------------------------

    Resolution: Done

I have fixed this. Have a look and inform me if it works for you. Note that I have refactored the name from ConfigInfoElement to GenericElement

> ConfigInfoElementDomAdapter doesnt define node types
> ----------------------------------------------------
>
>                 Key: GPD-129
>                 URL: http://jira.jboss.com/jira/browse/GPD-129
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:
> <?xml version="1.0"?>
> <process-definition name="Movie" version="11">
> <start-state name="Start">
> <transition to="Get MPEG Properties" />
> 	</start-state>
> <node name="Get MPEG Properties">
> 			<action class="SomeActionHandler"><send>010901</send>
> <keys>
> 		<entry>
>                                             <key>VarName</key>
>                                             <value>1122</value>
>                                 </entry>
> 	</keys>
> 	<receive>
> 		<element>030101</element>
> 		<element>030102</element>	
> 	</receive>
> </action>
> 				<transition to="End"/>	</node>
> <end-state name="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 lists.jboss.org  Tue Aug  7 09:21:08 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:21:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-131)
 XmlAdapter.getTextContent() appends null
In-Reply-To: <7479123.1186433404059.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31417195.1186492868911.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-131?page=all ]

Koen Aers closed GPD-131.
-------------------------

    Resolution: Done

> XmlAdapter.getTextContent() appends null
> ----------------------------------------
>
>                 Key: GPD-131
>                 URL: http://jira.jboss.com/jira/browse/GPD-131
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> the getTextContent() method in XmlAdapter class. There should be a null check while getting the node value (this issue also comes up when you have nested configInfoElements). So the following method in XmlAdapter.java : 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			buffer.append(list.item(i).getNodeValue());
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 
> should be changed to: 
> protected String getTextContent() {
> 		StringBuffer buffer = new StringBuffer();
> 		NodeList list = getNode().getChildNodes();
> 		for (int i = 0; i < list.getLength(); i++) {
> 			String nodeValue = list.item(i).getNodeValue();
> 			if (nodeValue != null)
> 				buffer.append(nodeValue);
> 		}
> 		return buffer.toString().trim();
> 	}
> 	 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:21:09 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Tue, 7 Aug 2007 09:21:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27064863.1186492869089.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371321 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

I made exactly the same change locally and this worked :)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:24:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6162622.1186493089492.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371322 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

I don't understand this issue.

Can you elaborate on the use case and describe more in detail what happens?

Regards,
Koen

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:24:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:24:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4765767.1186493089638.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371323 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

I mean, the array should contain only ConfigInfoElements right?

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:26:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 09:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22250297.1186493209582.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1048?page=comments#action_12371326 ] 
            
Mark Proctor commented on JBRULES-1048:
---------------------------------------

from an email with Peter Lin:
it should be configurable in the class. I don't know if kris added the configuration the IDE or not.

the reason for it was to have a smart guided editor for business users. for developers it makes more sense to only add the entire phrase instead of only showing the next words available.  I've gotten the same comment when I built a custom rule editor for pre-trade compliance.  the developers prefered to have a template style and see the entire thing.  the business users preferred guided editor that only showed the next words available.

the only real benefit of only showing the next word vs whole phrase is when the mapping file has thousands of entries. showing all available options with thousands of entries starts to get unusable. eclipse makes it less of a problem, since you can hit a letter and jump down to that section, but I find having too many options for a non-technical business user it doesn't go over so well. for compliance, we kept it down to a dozen or so.

in the DSLTree class you'll see getConditionChildrenList. if you call it with true, it will the entire phrase. I would go with what ever the users ask for myself. I suspect many of the users are primarily developers and not business users, so it's not a benefit for developers.

public ArrayList getConditionChildrenList(String text, boolean addChildren)

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Tue Aug  7 09:28:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 09:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26999748.1186493329337.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1048?page=comments#action_12371327 ] 
            
Mark Proctor commented on JBRULES-1048:
---------------------------------------

My preference is to have the previous default behaviour. Ideally someone can change this in the Eclipse preferences panel.

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Tue Aug  7 09:30:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 09:30:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1036) dialect errors
 if after import declarations
In-Reply-To: <1942890.1185648467658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5525673.1186493449358.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1036?page=comments#action_12371328 ] 
            
Mark Proctor commented on JBRULES-1036:
---------------------------------------

mic does not recal requesting this by design. So can we fix this for 4.0.1?

> dialect errors if after import declarations
> -------------------------------------------
>
>                 Key: JBRULES-1036
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1036
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> In the Shopping example if I have the dialect after the imports it 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 lists.jboss.org  Tue Aug  7 09:35:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-380) Allow
	annotations on packages
In-Reply-To: <28643571.1181232251888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18011506.1186493749300.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBBUILD-380?page=comments#action_12371329 ] 
            
Paul Gier commented on JBBUILD-380:
-----------------------------------

Waiting for this feature to be added to javassist.

> Allow annotations on packages
> -----------------------------
>
>                 Key: JBBUILD-380
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-380
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.1.2.GA
>
>
> Annotations on a package can be included in package-info.java.  Retro should allow annotations on packages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:37:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-379) Add support for
 getAnnotations vs getDeclaredAnnotations
In-Reply-To: <30513094.1181230094258.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31594215.1186493869951.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-379?page=all ]

Paul Gier updated JBBUILD-379:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Add support for getAnnotations vs getDeclaredAnnotations
> --------------------------------------------------------
>
>                 Key: JBBUILD-379
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-379
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>    Affects Versions:  JBossRetro-1.0.5.GA
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> Currently jboss retro does not differentiate between the getAnnotations() and getDeclaredAnnotations(), this functionality should be added in a future 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 lists.jboss.org  Tue Aug  7 09:37:50 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-380) Allow annotations
	on packages
In-Reply-To: <28643571.1181232251888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31034131.1186493870195.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-380?page=all ]

Paul Gier updated JBBUILD-380:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Allow annotations on packages
> -----------------------------
>
>                 Key: JBBUILD-380
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-380
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> Annotations on a package can be included in package-info.java.  Retro should allow annotations on packages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:37:50 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-383) Complete Retro
	Mavenization
In-Reply-To: <30433964.1181834471757.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10053038.1186493870315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-383?page=all ]

Paul Gier updated JBBUILD-383:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Complete Retro Mavenization
> ---------------------------
>
>                 Key: JBBUILD-383
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-383
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> The mavenization can be completed when the next surefire plugin is released.
> Also there needs to be a way to configure the manifest file for the runtime jar.
> Look into breaking retro into three modules: weaver, retro-runtime, and maven-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 lists.jboss.org  Tue Aug  7 09:37:50 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 09:37:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-385) Research
 customizing package names for each release or each project.
In-Reply-To: <1040423.1181846771687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6352004.1186493870456.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-385?page=all ]

Paul Gier updated JBBUILD-385:
------------------------------

    Fix Version/s: JBossRetro-1.2.0.GA
                       (was: JBossRetro-1.1.2.GA)

> Research customizing package names for each release or each project.
> --------------------------------------------------------------------
>
>                 Key: JBBUILD-385
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-385
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.2.0.GA
>
>
> It could be helpful for backwards compatibility to have unique package names for each release of the retro runtime.  That way multiple versions of retro included in a product with multiple components could co-exist.
> The projects that require the retro runtime would be run against a particular version of retro and point to the appropriate fully qualified class names.  So a package name could be something like:
> org.jboss.retro.runtime_1_1_0.*

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:45:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-135) bendpoints are not
 properly drawn when reading a processdefinition from disk
In-Reply-To: <18689252.1186479032370.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <777692.1186494349531.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-135?page=all ]

Koen Aers closed GPD-135.
-------------------------

    Resolution: Done

> bendpoints are not properly drawn when reading a processdefinition from disk
> ----------------------------------------------------------------------------
>
>                 Key: GPD-135
>                 URL: http://jira.jboss.com/jira/browse/GPD-135
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 09:53:56 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 09:53:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-132) random duedate
 attributes appear on task elements
In-Reply-To: <20412380.1186477429420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12306168.1186494836808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-132?page=all ]

Koen Aers closed GPD-132.
-------------------------

    Resolution: Done

> random duedate attributes appear on task elements
> -------------------------------------------------
>
>                 Key: GPD-132
>                 URL: http://jira.jboss.com/jira/browse/GPD-132
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> while working with the eclipse designer plugin, I have never intentionally entered anything into the duedate text input, yet occasionally, a duedate attribute is inserted into the resulting xml, this causes an exception in the console webapp

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:00:49 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 7 Aug 2007 10:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
In-Reply-To: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17930583.1186495249362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4593?page=all ]

Anil Saldhana updated JBAS-4593:
--------------------------------

    Description: 
[description pasted from support case]

After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:

found a path to the target: 26093 (depth: 5)
0 0 Heap root
26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
160611 0 Instance: [Ljava/lang/Object;
161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
217357 0 Instance: Ljavax/management/Notification;
26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;

So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.

Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.



  was:
[description pasted from support case]

After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.amfam" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:

found a path to the target: 26093 (depth: 5)
0 0 Heap root
26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
160611 0 Instance: [Ljava/lang/Object;
161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
217357 0 Instance: Ljavax/management/Notification;
26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;

So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.

Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.




> Leak in org/jboss/mx/loading/UnifiedClassLoader3
> ------------------------------------------------
>
>                 Key: JBAS-4593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Scott M Stark
>
> [description pasted from support case]
> After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:
> found a path to the target: 26093 (depth: 5)
> 0 0 Heap root
> 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
> 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
> 160611 0 Instance: [Ljava/lang/Object;
> 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
> 217357 0 Instance: Ljavax/management/Notification;
> 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;
> So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.
> Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:02:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 10:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20290338.1186495369340.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371335 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

I think this is basically a problem in the console. 

Tom has asked a long time ago to *not* generate a name for the transition if there is only one and generate a name starting with the second transition. He even fixed this himself if I remember correctly. Now I know that this strategy is debatable and that there are a number of prominent jBPM users that prefer a default name in all cases (I think Ronald is amongst them). I even think there is a JIRA issue to reintroduce this, but I don't remember which one from the top of my head. 

The obvious workaround is to give your transitions a name as you found out.

Note that validation is pointless because the jPDL xsd does not mandate the name for the transition.

Regards,
Koen

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:04:57 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 10:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25612840.1186495497308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-133?page=all ]

Koen Aers updated GPD-133:
--------------------------

        Fix Version/s:     (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s:     (was: jBPM JPDL Designer 3.1.0.beta1)

I will not include this different naming strategy for the upcoming release. 

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:23:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Tue, 7 Aug 2007 10:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1029) Can't use JMock
 to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30178893.1186496629363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1029?page=comments#action_12371338 ] 
            
John Doe commented on JBRULES-1029:
-----------------------------------

I recently got chance to test this and foudn very strange issue after I update from svn trunk and built/installed things with maven:

org.drools.rule.InvalidRulePackage: Unable to build expression for 'from' node 'RuleHelper.search(content,"pattern","column")' : [Rule name=Verify_1, agendaGroup=MAIN, salience=0, no-loop=false]
Rule Compilation error : [Rule name=Verify_1, agendaGroup=MAIN, salience=0, no-loop=false]
	sample/Rule_Verify_1_0.java (5:175) : ResultsInterface cannot be resolved to a type

	at org.drools.rule.Package.checkValidity(Package.java:410)
	at BasicRuleFlowTest.testGenericFlow(BasicRuleFlowTest.java:31)
	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:164)
	at junit.framework.TestCase.runBare(TestCase.java:130)
	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:120)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


the rule is exactly the same, could you please take a look at this?

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:25:49 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Tue, 7 Aug 2007 10:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-570) Complete thread
 naming for all channel threads
Message-ID: <23416128.1186496749399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Complete thread naming for all channel threads
----------------------------------------------

                 Key: JGRP-570
                 URL: http://jira.jboss.com/jira/browse/JGRP-570
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.6


We have improved thread naming in Jgroups 2.5 release. However, we still have threads in protocols above TP that are named independently of TP threads - they follow different naming pattern. We should investigate how to consistently name all threads that belong to one channel. Should we pass ThreadNamingPattern as and event through 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 lists.jboss.org  Tue Aug  7 10:25:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Tue, 7 Aug 2007 10:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1029) Can't use JMock
 to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29477702.1186496749586.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1029?page=all ]

John Doe reopened JBRULES-1029:
-------------------------------

             
I'm not sure, but probably this issue is related to some MVEL issue which should be fixed in trunk - but actually isn't?

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:30:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Tue, 7 Aug 2007 10:30:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1029) Can't use JMock
	to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24280805.1186497049347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1029?page=all ]

John Doe updated JBRULES-1029:
------------------------------

    Attachment: drools.zip

Sample package which illustrates the issue

use 'mvn test' to see it in action

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: drools.zip
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 10:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 10:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-121) remove lookup of
 current editor to obtain commandstack
In-Reply-To: <32250260.1185378347021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27864075.1186498729265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-121?page=all ]

Koen Aers closed GPD-121.
-------------------------

    Resolution: Done

> remove lookup of current editor to obtain commandstack
> ------------------------------------------------------
>
>                 Key: GPD-121
>                 URL: http://jira.jboss.com/jira/browse/GPD-121
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 11:02:52 2007
From: jira-events at lists.jboss.org (Hany Mesha (JIRA))
Date: Tue, 7 Aug 2007 11:02:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2861) HttpSession sharing
 between WAR modules
Message-ID: <12436685.1186498972371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2861?page=all ]

Hany Mesha reassigned JBAS-2861:
--------------------------------

    Assignee: Hany Mesha  (was: Brian Stansberry)

> HttpSession sharing between WAR modules
> ---------------------------------------
>
>                 Key: JBAS-2861
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2861
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>    Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final
>            Reporter: Brian Stansberry
>         Assigned To: Hany Mesha
>             Fix For: JBossAS-4.2.2.GA
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.html?Open
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.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 lists.jboss.org  Tue Aug  7 11:02:52 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 11:02:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13092053.1186498972485.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371345 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Matthew, can you have a check if this works for you and close the issue if it does?

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 11:58:49 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 11:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1622) Implement
 "admin" portlet mode
Message-ID: <22138593.1186502329360.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement "admin" portlet mode
------------------------------

                 Key: JBPORTAL-1622
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1622
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 12:23:49 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 7 Aug 2007 12:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SWAP-25) Update MyFaces JSF
 tutorial portlet to work with 2.6 and AS 4.2
Message-ID: <25738357.1186503829619.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update MyFaces JSF tutorial portlet to work with 2.6 and AS 4.2
---------------------------------------------------------------

                 Key: SWAP-25
                 URL: http://jira.jboss.com/jira/browse/SWAP-25
             Project: PortletSwap
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         Assigned To: Julien Viet


Tutorial portlet is out of date as MyFaces is not bundled anymore.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 12:23:49 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 7 Aug 2007 12:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SWAP-26) Add RI JSF portlet for
	AS 4.2
Message-ID: <24942180.1186503829752.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add RI JSF portlet for AS 4.2
-----------------------------

                 Key: SWAP-26
                 URL: http://jira.jboss.com/jira/browse/SWAP-26
             Project: PortletSwap
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portlets
            Reporter: Chris Laprun
         Assigned To: Julien Viet


Add a JSF portlet example showing how to use JSF RI to create a 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 lists.jboss.org  Tue Aug  7 12:58:49 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 7 Aug 2007 12:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4587)
 NoClassDefFoundError java.lang.System
In-Reply-To: <6030030.1185874069379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16168483.1186505929456.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4587?page=comments#action_12371354 ] 
            
Aleksandar Kostadinov commented on JBAS-4587:
---------------------------------------------

Issue seems to have gone away somewhere after build  25 
http://dev45.qa.atl.jboss.com:8585/hudson/job/JBoss_AS_Testsuite_HEAD-jdk15/25/

I'll keep it until you tell me so you could investigate.

> NoClassDefFoundError java.lang.System
> -------------------------------------
>
>                 Key: JBAS-4587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4587
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions:  JBossAS-5.0.0.Beta3
>         Environment: QA Lab, VM, Sun JDK 1.5
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Scott M Stark
>         Attachments: server_log.zip, server_log_1.zip
>
>
> In the QA Lab we come across an issue when trying to run the JBoss AS test suite on VMs (see trace level log bolow). Consequences are that minimal server doesn't shutdown and test suite fails on starting the all configuration.
> To reproduce:
> Can be reproduced on a VM with sun jdk15 versions including 1.5.0_12. 
> Try ssh to qa01.qa.atl.jboss.com. On any issue ask in jboss-qa-internal at redhat.com or #jbossqa
> Checkout trunk.
> build/build.sh
> testsuite/build.sh jboss-minimal-tests
> The issue doesn't occur on physical machines as well jrockit is not affected.
> If that could be of any help I've found two issues with java.lang.System not found and gcj.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6371479
> http://www.linuxhelpforum.com/showthread.php?t=809687
> 2 server trace logs attached. Part of log see below:
> 2007-07-31 05:04:11,222 DEBUG [org.jboss.deployers.plugins.deployers.DeployersIm
> pl] Fully Undeployed vfsfile:/qa/services/hudson/hudson_workspace/workspace/JBos
> s_AS_Testsuite_HEAD-jdk15/src/build/output/jboss-5.0.0.Beta3/server/minimal/depl
> oy/shutdown.sar
> 2007-07-31 05:04:11,223 TRACE [org.jboss.system.server.profileservice.hotdeploy.
> HDScanner] End deployment scan
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=0
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=1
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,224 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,225 ERROR [STDERR] Exception in thread "ExitOnShutdown"
> 2007-07-31 05:04:11,226 ERROR [STDERR] java.lang.NoClassDefFoundError: java/lang
> /System
> 2007-07-31 05:04:11,226 ERROR [STDERR]  at org.jboss.test.jmx.shutdown.ExitOnShu
> tdown$1.run(ExitOnShutdown.java:52)
> 2007-07-31 05:04:11,227 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 lists.jboss.org  Tue Aug  7 13:54:49 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 7 Aug 2007 13:54:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26384063.1186509289437.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371355 ] 
            
Imran Naqvi commented on GPD-130:
---------------------------------

yes th array should only contain ConfigInfoElements. But the following lines in ConfigInfoElements.getConfigInfoElements() always returns a class cast exception:

return (ConfigInfoElement[])configInfoElements.toArray(new Object[configInfoElements.size()]);

this is because we are trying to directly cast from Object[] to ConfigInfoElement[]. Even though every element in Object[] is a ConfigInfoElement, it is still not allowed to have two references to an array of different types. Instead something like this would work:

                                          ConfigInfoElement[] elements = new ConfigInfoElement[configInfoElements.size()];
		for (int i = 0; i < configInfoElements.size(); i++)
			elements[i] = (ConfigInfoElement) this.configInfoElements.get(i);

		return elements;

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 14:07:09 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 14:07:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1623) Create "Admin"
 icon for the different themes for the new admin portlet mode
Message-ID: <19138744.1186510029362.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create "Admin" icon for the different themes for the new admin portlet mode
---------------------------------------------------------------------------

                 Key: JBPORTAL-1623
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1623
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.6.3 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 lists.jboss.org  Tue Aug  7 14:26:49 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 14:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1624) Create icon for
 the admin
 mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
Message-ID: <5089473.1186511209298.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create icon for the admin mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
--------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1624
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1624
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 14:34:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 14:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1161) PojoCache
 loadtime example failure
In-Reply-To: <17873568.1186438129330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15232704.1186511689335.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1161?page=all ]

Jason T. Greene resolved JBCACHE-1161.
--------------------------------------

    Resolution: Done

fixed, retaged

> PojoCache loadtime example failure
> ----------------------------------
>
>                 Key: JBCACHE-1161
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1161
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Jason T. Greene
>
> The following exceptions occurs when running the example under JBossCache-pojo-2.0.0.GA\examples\PojoCache\loadtime
> "build.bat compile" &  "build.bat run.loadtime.example"
>      [java] Exception in thread "main" java.lang.IllegalArgumentException: PojoCache.putObject(): Object type is neither  aspectized nor Serializable nor an array of prim
> itives. Object class name is examples.Student
>      [java]     at org.jboss.cache.pojo.util.AopUtil.checkObjectType(AopUtil.java:125)
>      [java]     at org.jboss.cache.pojo.interceptors.CheckNonSerializableInterceptor.invoke(CheckNonSerializableInterceptor.java:36)
>      [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
>      [java]     at org.jboss.cache.pojo.interceptors.CheckIdInterceptor.invoke(CheckIdInterceptor.java:33)
>      [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
>      [java]     at org.jboss.cache.pojo.interceptors.PojoBeginInterceptor.invoke(PojoBeginInterceptor.java:36)
>      [java]     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl$attach_3085019539260813833.invokeNext(PojoCacheImpl$attach_3085019539260813833.java)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
>      [java]     at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
>      [java]     at test.examples.StudentMaintTest.testPropagation(StudentMaintTest.java:99)
>      [java]     at test.examples.StudentMaintTest.main(StudentMaintTest.java:145)
>      [java] Java Result: 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 lists.jboss.org  Tue Aug  7 14:46:49 2007
From: jira-events at lists.jboss.org (Rajesh Rajasekaran (JIRA))
Date: Tue, 7 Aug 2007 14:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1160)
 org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
In-Reply-To: <19125763.1186437829351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21097310.1186512409723.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1160?page=comments#action_12371365 ] 
            
Rajesh Rajasekaran commented on JBCACHE-1160:
---------------------------------------------

Jason, this is the other issue with the 2.0.0.GA release.

> org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
> -------------------------------------------------------------------------
>
>                 Key: JBCACHE-1160
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1160
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Jason T. Greene
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/20070806045019/results/org/jboss/cache/pojo/rollback/InMemoryTxUndoTest(tcp).html
> The test attaches a second Person object to an existing node (Person object) within the scope of a transaction and rolls back.
> The following exception occurs when trying to retrieve the first object.
> testSimpleTxWithRollback3	
> Error	org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4
> org.jboss.cache.pojo.PojoCacheAlreadyDetachedException: org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4 at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.verifyAttached(CacheFieldInterceptor.java:177) at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.invoke(CacheFieldInterceptor.java:153) at org.jboss.cache.pojo.test.Person$age_Get.invokeNext(Person$age_Get.java) at org.jboss.cache.pojo.test.Person.age_r_$aop(Person.java) at org.jboss.cache.pojo.test.Person.getAge(Person.java:76) at org.jboss.cache.pojo.rollback.InMemoryTxUndoTest.testSimpleTxWithRollback3(InMemoryTxUndoTest.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:03:49 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Tue, 7 Aug 2007 15:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-868)
 java.lang.IllegalArgumentException: Unable to find operation XYZ for
 dependent beans in seperate jars
In-Reply-To: <5235901.1170897390091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10269495.1186513429387.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-868?page=comments#action_12371368 ] 
            
William DeCoste commented on EJBTHREE-868:
------------------------------------------

Could you please open a support ticket so that we can track your problem via the ticket instead of this closed JIRA?

> java.lang.IllegalArgumentException: Unable to find operation XYZ for dependent beans in seperate jars
> -----------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-868
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-868
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.0 GA
>
>
> java.lang.IllegalArgumentException: Unable to find operation sayHello()
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
> 	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
> 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
> 	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:263)
> 	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:999)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:454)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261)
> Caused by: java.lang.IllegalArgumentException: Unable to find operation sayHello()
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:231)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy89.sayHello(Unknown Source)
> 	at org.jboss.ejb3.test.dependency.ABean.getHelloB(ABean.java:18)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:18:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 15:18:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21539574.1186514330822.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371371 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

Hm, I think the roblem is that I am using new Object[configInfoElements.size()] as the parameter for toArray. This should be new ConfigInfoElement[configInfoElements.size()]

I will change the paramter and commit. It would be great if you could test if it works

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:22:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 15:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4744251.1186514569646.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-130?page=comments#action_12371372 ] 
            
Koen Aers commented on GPD-130:
-------------------------------

Oh, in case you didn't remark it yet, I refactored the ConfigInfoElement class. It is called GenericElement now

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 15:25:06 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 7 Aug 2007 15:25:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-130) Class Cast exception
 in ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6826272.1186514706900.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-130?page=all ]

Koen Aers resolved GPD-130.
---------------------------

    Resolution: Done

Scream if it doesn't work! ;-)

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 16:01:53 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 16:01:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1625) Portlet mode
 "admin" for portlet administration
Message-ID: <32179551.1186516913488.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portlet mode "admin" for portlet administration
-----------------------------------------------

                 Key: JBPORTAL-1625
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1625
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 16:01:55 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 16:01:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13216473.1186516915019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-123?page=all ]

Scott M Stark updated JBMICROCONT-123:
--------------------------------------

               Issue Type: Bug  (was: Task)
    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4071717
                 Assignee: Scott M Stark  (was: Ales Justin)

This is actually a bug as this method does not work. See the org.jboss.test.classinfo.test.ClassInfoArrayTest.testArrayType() test.


> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For:  JBossMC-2.2.0.GA
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Tue Aug  7 16:07:53 2007
From: jira-events at lists.jboss.org (James Cobb (JIRA))
Date: Tue, 7 Aug 2007 16:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (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: <12188165.1186517273987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-128?page=all ]

James Cobb reassigned JBFORUMS-128:
-----------------------------------

    Assignee: Meriah Garrett  (was: James Cobb)

The global catch all for the forums project.

> 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
>          Components: Forum View Layer, Portlet Productization
>            Reporter: Sohil Shah
>         Assigned To: Meriah Garrett
>             Fix For: 1.0.1 RC
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 16:09:49 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 7 Aug 2007 16:09:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1622) Implement
 "admin" portlet mode
In-Reply-To: <22138593.1186502329360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13023950.1186517389308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1622?page=all ]

Julien Viet resolved JBPORTAL-1622.
-----------------------------------

    Resolution: Done

> Implement "admin" portlet mode
> ------------------------------
>
>                 Key: JBPORTAL-1622
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1622
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug  7 17:21:49 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 7 Aug 2007 17:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-390) Update jboss retro
 site on jboss.org.
In-Reply-To: <31686227.1183489257627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7672113.1186521709313.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-390?page=all ]

Paul Gier closed JBBUILD-390.
-----------------------------

    Resolution: Done

Some basic documentation has been added to the site, and downloadable zip files have been added.

> Update jboss retro site on jboss.org.
> -------------------------------------
>
>                 Key: JBBUILD-390
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-390
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: JBossRetro-1.1.2.GA
>
>
> Update jbossretro on jboss.org (http://labs.jboss.com/jbossretro).  The site content should be generated by maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 17:57:55 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Tue, 7 Aug 2007 17:57:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
Message-ID: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>

maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
----------------------------------------------------------------------------------

                 Key: JBAOP-453
                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
             Project: JBoss AOP
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: maven 2
            Reporter: Anders Andersen


In order to use the plugin I have to add the following dependencies to the client artifact dependency list.

    <dependency>
      <groupId>org.jboss.maven.plugins</groupId>
      <artifactId>maven-jbossaop-plugin</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-aop</artifactId>
      <version>2.0.0.alpha2</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-common</artifactId>
      <version>4.0.2</version>
    </dependency>
    <dependency>
      <groupId>concurrent</groupId>
      <artifactId>concurrent</artifactId>
      <version>1.3.4</version>
    </dependency>

This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.

See lists below.
I think the statement
      cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
is wrong.

I tried to include only project.getPluginArtifacts(), but it gave me a NPE
So I am not 100% sure what the code solution should be
but it is not good to having maven artifacts in the resulting dependency list of the client-artifact

list: (resulting depenency list)
The ** marked should not be there

**/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
/Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
/Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
/Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
/Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
/Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
/Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
/Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
/Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
/Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
/Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
/Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
/Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
/Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
/Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
/Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
/Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
/Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
/Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
/Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
/Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
/Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
/Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
/Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
/Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
/Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
/Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
/Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
/Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
/Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
/Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
/Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
/Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
/Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
/Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
/Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
/Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
/Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
/Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
/Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
/Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
**/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
/Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
/Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
/Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
/Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
/Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
**/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
/Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
/Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
/Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
/Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
/Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
/Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
/Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
**/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
/Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
/Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Tue Aug  7 18:18:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Tue, 7 Aug 2007 18:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10086541.1186525129403.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371395 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

hi all - sorry ive been ill for a few days and it has delayed my verification of this. everything looks to be working fine. 

as far as my intentions with MAX_VALUE, i was thinking of the difference of a Priority 1 problem vs a Priority 2 problem. it may or may not make sense in that context but certainly as i began working with using the priorities it became more and more obvious that descending priorities was very counter-intuitive. i like the use of 0 as the default much better! 

thanks to everyone for the great discussion. i hope this helps make it easier for people to make extensions!

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 18:18:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Tue, 7 Aug 2007 18:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-111) Add ability to forward
 and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33406272.1186525129559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Matthew Sandoz closed GPD-111.
------------------------------


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 20:19:49 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 20:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19639838.1186532389452.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-123?page=all ]

Scott M Stark updated JBMICROCONT-123:
--------------------------------------

    Comment: was deleted

> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For:  JBossMC-2.2.0.GA
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Tue Aug  7 20:28:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 20:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
Message-ID: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Node.clearData() does not rollback correctly
--------------------------------------------

                 Key: JBCACHE-1162
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Jason T. Greene
         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 lists.jboss.org  Tue Aug  7 20:28:49 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 20:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11656263.1186532929710.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-123?page=all ]

Scott M Stark reassigned JBMICROCONT-123:
-----------------------------------------

    Assignee: Ales Justin  (was: Scott M Stark)

> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>            Priority: Minor
>             Fix For:  JBossMC-2.2.0.GA
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Tue Aug  7 20:34:00 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Aug 2007 20:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-202) Primative
 arrays are not
 handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
Message-ID: <17430949.1186533240797.JavaMail.jira@cloud.prod.atl2.jboss.com>

Primative arrays are not handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
----------------------------------------------------------------------------------------------

                 Key: JBMICROCONT-202
                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-202
             Project: JBoss MicroContainer
          Issue Type: Bug
          Components: MetaData
    Affects Versions:  JBossMC_2_0_0 Beta3
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossMC-2.0.0.Beta4


When looking at obtaining MetaType/MetaValues for primative arrays I see problems with the primitive array type name ("[char" vs "[C") and attempts to cast to Object[] in DefaultMetaValueFactory. The referenced forum discusses the 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 lists.jboss.org  Tue Aug  7 20:35:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 20:35:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
In-Reply-To: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13361121.1186533349345.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1162?page=all ]

Jason T. Greene updated JBCACHE-1162:
-------------------------------------

    Fix Version/s: 2.0.0.GA

> Node.clearData() does not rollback correctly
> --------------------------------------------
>
>                 Key: JBCACHE-1162
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 21:40:00 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 7 Aug 2007 21:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1064) "->" notation
 for predicates missing in documentation
In-Reply-To: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23830433.1186537200895.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1064?page=comments#action_12371401 ] 
            
Mark Proctor commented on JBRULES-1064:
---------------------------------------

-> is now deprecated, its not just needed now.

Person( girlAge : age, sex = "F" )
Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' ) 

is now, notice the boyAge does not need binding, as it will determine and bind "age" as part of the autovivification process.
Person( girlAge : age, sex = "F" )
Person( eval( girlAge == age + 2 ), sex = 'M' ) 

You can ofcourse still still bind the boyAge, but generally its not preferred any more. Basically predicates where where focused on a single field are no longer needed as we determine the used and bound fields on the fly, we also now call then inline-eval. Predicate, while the traditional name, was dropped, this is partly in preparation for when we start to support backward chaining and will use the term predicate in the prolog sense.
Person( boyAge : age, eval( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' ).

I'll close this one off in a day or so, if I don't hear any further feedback.

> "->" notation for predicates missing in documentation
> -----------------------------------------------------
>
>                 Key: JBRULES-1064
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>            Priority: Minor
>
> the notation "->" for adressing complex terms is missing from 4.0.0 documentation.
> It has been "return value operator" in 3.0.6:
> <quoted from 3.0.6>
> Example 3.13. Return Value operator
> Person( girlAge : age, sex = "F" )
> Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
> </quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 22:15:51 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Aug 2007 22:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2299) OutOfMemory error when
 repetatively deploying and undeploying with 10 minute interval
Message-ID: <115029.1186539351637.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic closed JBAS-2299.
---------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
       Resolution: Rejected

This is a Jakarta commons issue... not a JBoss issue

I have created a testcase that replicates this and submitted to them...  

https://issues.apache.org/jira/browse/BEANUTILS-291


There is nothing else we can do about this now.. we could just wait and see if they will fix it!

> 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
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Tue Aug  7 22:26:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 22:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
In-Reply-To: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24045604.1186540009444.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1162?page=all ]

Jason T. Greene resolved JBCACHE-1162.
--------------------------------------

    Resolution: Done

> Node.clearData() does not rollback correctly
> --------------------------------------------
>
>                 Key: JBCACHE-1162
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 22:26:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 22:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1162) Node.clearData()
 does not rollback correctly
In-Reply-To: <15910784.1186532929521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2155866.1186540009557.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1162?page=all ]

Jason T. Greene closed JBCACHE-1162.
------------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> Node.clearData() does not rollback correctly
> --------------------------------------------
>
>                 Key: JBCACHE-1162
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1162
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Jason T. Greene
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug  7 22:26:49 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 7 Aug 2007 22:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1160)
 org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
In-Reply-To: <19125763.1186437829351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19110905.1186540009726.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1160?page=all ]

Jason T. Greene closed JBCACHE-1160.
------------------------------------

    Fix Version/s: 2.0.0.GA
       Resolution: Done

> org.jboss.cache.pojo.rollback.InMemoryTxUndoTest (tcp & udp) test failure
> -------------------------------------------------------------------------
>
>                 Key: JBCACHE-1160
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1160
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/20070806045019/results/org/jboss/cache/pojo/rollback/InMemoryTxUndoTest(tcp).html
> The test attaches a second Person object to an existing node (Person object) within the scope of a transaction and rolls back.
> The following exception occurs when trying to retrieve the first object.
> testSimpleTxWithRollback3	
> Error	org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4
> org.jboss.cache.pojo.PojoCacheAlreadyDetachedException: org.jboss.cache.pojo.test.Person at 140984b has possibly been detached remotely. Internal id: /__JBossInternal__/a/_ID_/1s225g61-ezjyl3-f50xq5j0-1-f50xq5o0-4 at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.verifyAttached(CacheFieldInterceptor.java:177) at org.jboss.cache.pojo.interceptors.dynamic.CacheFieldInterceptor.invoke(CacheFieldInterceptor.java:153) at org.jboss.cache.pojo.test.Person$age_Get.invokeNext(Person$age_Get.java) at org.jboss.cache.pojo.test.Person.age_r_$aop(Person.java) at org.jboss.cache.pojo.test.Person.getAge(Person.java:76) at org.jboss.cache.pojo.rollback.InMemoryTxUndoTest.testSimpleTxWithRollback3(InMemoryTxUndoTest.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 01:47:49 2007
From: jira-events at lists.jboss.org (Tong Lee (JIRA))
Date: Wed, 8 Aug 2007 01:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1065) Unable to return
 Declaration for identifier
Message-ID: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to return Declaration for identifier
-------------------------------------------

                 Key: JBRULES-1065
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Java 1.6
            Reporter: Tong Lee
         Assigned To: Mark Proctor


I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:

Fact/bean object code:
public class Record {
private String abc;
private String xyz;
public String getAbc()...
public String getXyz()...
...
}

DRL code:
rule "..."
  when
    $record : Record ( abc == xyz)
  then
    ....
end

The PackageBuilder can not resolve the "xyz"

I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
rule "..."
  when
    r: Record ( )
    $record : Record ( abc == r.xyz)
  then
    ....
end

Any feedback with this is greatly 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 lists.jboss.org  Wed Aug  8 03:39:49 2007
From: jira-events at lists.jboss.org (Tuomas Kiviaho (JIRA))
Date: Wed, 8 Aug 2007 03:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5213894.1186558789698.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-992?page=comments#action_12371406 ] 
            
Tuomas Kiviaho commented on JBRULES-992:
----------------------------------------

JavaDialect seems to have been fixed in trunk. There has been some development around jsr199 at Commons JCI that would make both jdt and jalopy optional thus reducing the external dependencies even further.

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Mark Proctor
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Wed Aug  8 04:36:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 04:36:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-134) form file names
 generated from the task dialogue are unstable
In-Reply-To: <9189503.1186477849412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6432042.1186562209472.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-134?page=comments#action_12371409 ] 
            
Ross McDonald commented on GPD-134:
-----------------------------------

Hi sorry for the delay, I never tried this with HSQL, you are probably right about it being a more general JBPM issue.

> form file names generated from the task dialogue are unstable
> -------------------------------------------------------------
>
>                 Key: GPD-134
>                 URL: http://jira.jboss.com/jira/browse/GPD-134
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: osx macbook pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> the form names generated from the task dialogue are sensitive to content...
> 'fbm-rejects.xhtml' is ok, and is stored in the DB fine when deployed,
> 'fbm-rejects-psr.xhtml' is not stored in the DB when deployed and therefore the form does not display within the jbpm-console
> the DB schema says the name field is varchar(255), which suggests that perhaps the second hyphen in the name is causing a problem somewhere

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 04:38:49 2007
From: jira-events at lists.jboss.org (Matt Drees (JIRA))
Date: Wed, 8 Aug 2007 04:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1066)
 org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not
 serializable
Message-ID: <23034283.1186562329494.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not serializable
---------------------------------------------------------------------------------------

                 Key: JBRULES-1066
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1066
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: seam cvs (2007-08-05), which includes drools 4.0.0.GA, I believe
            Reporter: Matt Drees
         Assigned To: Mark Proctor
            Priority: Minor


I sometimes get a java.io.NotSerializableException: org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction when restarting my seam webapp.  It seems that the problem is simply that WorkingMemoryReteAssertAction doesn't implement Serializable.  This email (http://osdir.com/ml/java.drools.user/2006-12/msg00163.html) seems to indicate that it should, but it apparently hasn't been 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 lists.jboss.org  Wed Aug  8 04:42:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 04:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12489081.1186562569342.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371410 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

Hi Koen, no problem there, as you said I figured out how to fix this by naming every transition.  Is the upcoming release the one with support for custom nodes ? Is there a reference with info about it, I am very keen for more details :-)

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 04:59:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Aug 2007 04:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-519) Replace
 BoundedList/List with java.util(.concurrent) class
In-Reply-To: <25866563.1180426750122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13446546.1186563589407.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-519?page=comments#action_12371413 ] 
            
Bela Ban commented on JGRP-519:
-------------------------------

removed List

> Replace BoundedList/List with java.util(.concurrent) class
> ----------------------------------------------------------
>
>                 Key: JGRP-519
>                 URL: http://jira.jboss.com/jira/browse/JGRP-519
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> E.g. BoundedList could be a subclass of java.util.LinkedList

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:28:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10760341.1186565329791.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371422 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

yes, but there is not yet a lot of info except some forum entries an jira issues. 

i plan to write an article about it soon.

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:46:49 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 8 Aug 2007 05:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23264550.1186566409555.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-453?page=all ]

Stale Pedersen reassigned JBAOP-453:
------------------------------------

    Assignee: Stale Pedersen

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 05:57:31 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 05:57:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1027) Timeout method
 gets called with an unspecified caller identity
Message-ID: <6643972.1186567051460.JavaMail.jira@cloud.prod.atl2.jboss.com>

Timeout method gets called with an unspecified caller identity
--------------------------------------------------------------

                 Key: EJBTHREE-1027
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1027
             Project: EJB 3.0
          Issue Type: Bug
          Components: Security
    Affects Versions: AS 4.2.1.GA
            Reporter: Carlo de Wolf


Having a secured bean with a timeout method with @PermitAll, but without an unauthenticatedIdentity will lead to a 'random' identity being used to call the method or no identity at all. The last one leads to EJBAccessExceptions.

Spec 18.2.2:
"Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity."

We must disallow all calls to a timeout method if unauthenticatedIdentity is not 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 lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1027) Timeout method
 gets called with an unspecified caller identity
In-Reply-To: <6643972.1186567051460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <215766.1186567129426.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1027?page=comments#action_12371428 ] 
            
Carlo de Wolf commented on EJBTHREE-1027:
-----------------------------------------

Unit test: timer

> Timeout method gets called with an unspecified caller identity
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1027
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1027
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: AS 4.2.1.GA
>            Reporter: Carlo de Wolf
>
> Having a secured bean with a timeout method with @PermitAll, but without an unauthenticatedIdentity will lead to a 'random' identity being used to call the method or no identity at all. The last one leads to EJBAccessExceptions.
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity."
> We must disallow all calls to a timeout method if unauthenticatedIdentity is not 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 lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-126) CLONE -New Page Flow
 broken - exception
Message-ID: <19612880.1186567129517.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-126?page=all ]

Koen Aers closed GPD-126.
-------------------------


> CLONE -New Page Flow broken - exception
> ---------------------------------------
>
>                 Key: GPD-126
>                 URL: http://jira.jboss.com/jira/browse/GPD-126
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Blocker
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> Ctrl+N, select Page Flow and Next or Finish gives multiple errors and the dialog is just stuck:
> java.lang.IllegalArgumentException: Path must include project and resource name: /
> at org.eclipse.core.runtime.Assert.isLegal(Assert.java:62)
> at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1625)
> at org.eclipse.core.internal.resources.Container.getFolder(Container.java:137)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getProcessFolder(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.performFinish(Unknown Source)
> at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:742
> java.lang.NullPointerException
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getRootForEmbeddingProject(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.initContainerName(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.init(Unknown Source)
> at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.addPages(Unknown Source)
> at org.eclipse.jface.wizard.WizardSelectionPage.getNextPage(WizardSelectionPage.java:113)
> java.lang.IllegalArgumentException: Argument cannot be null
> 	at org.eclipse.swt.SWT.error(SWT.java:3547)
> 	at org.eclipse.swt.SWT.error(SWT.java:3481)
> 	at org.eclipse.swt.SWT.error(SWT.java:3452)
> 	at org.eclipse.swt.widgets.Widget.error(Widget.java:438)
> 	at org.eclipse.swt.widgets.Text.setText(Text.java:1870)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createContainerField(Unknown Source)
> 	at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createControl(Unknown Source)
> 	at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170)
> 	at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:669)
> 	at org.eclipse.jface.wizard.WizardDialog.setWizard(WizardDialog.java:1083)
> 	at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1142)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-127) CLONE -Page flow is
 under "JBoss Seam" instead of "Seam" in Wizard dialog
Message-ID: <5982020.1186567129592.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-127?page=all ]

Koen Aers closed GPD-127.
-------------------------


> CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog
> -------------------------------------------------------------------------
>
>                 Key: GPD-127
>                 URL: http://jira.jboss.com/jira/browse/GPD-127
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> jbpm should use the same id as "Seam" from jbosstools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 05:58:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 05:58:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7301572.1186567129765.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-128?page=all ]

Koen Aers closed GPD-128.
-------------------------


> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Wed Aug  8 06:00:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-129)
 ConfigInfoElementDomAdapter doesnt define node types
In-Reply-To: <22120733.1186433029492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1897555.1186567250239.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-129?page=all ]

Koen Aers closed GPD-129.
-------------------------


i am getting ready for the release, feel free to reopen if this is still a problem

> ConfigInfoElementDomAdapter doesnt define node types
> ----------------------------------------------------
>
>                 Key: GPD-129
>                 URL: http://jira.jboss.com/jira/browse/GPD-129
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElementDomAdapter class needs to defined the getNodeTypes() method and return "configInfoElement" as one of its possible types. Otherwise it isnt possible to have nested ConfigInfoElements. For example in the following template, the nested config info elements wouldnt work:
> <?xml version="1.0"?>
> <process-definition name="Movie" version="11">
> <start-state name="Start">
> <transition to="Get MPEG Properties" />
> 	</start-state>
> <node name="Get MPEG Properties">
> 			<action class="SomeActionHandler"><send>010901</send>
> <keys>
> 		<entry>
>                                             <key>VarName</key>
>                                             <value>1122</value>
>                                 </entry>
> 	</keys>
> 	<receive>
> 		<element>030101</element>
> 		<element>030102</element>	
> 	</receive>
> </action>
> 				<transition to="End"/>	</node>
> <end-state name="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 lists.jboss.org  Wed Aug  8 06:00:50 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-130) Class Cast exception in
 ConfigInfoElement.getConfigInfoElements()
In-Reply-To: <31492186.1186433269332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25636536.1186567250359.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-130?page=all ]

Koen Aers closed GPD-130.
-------------------------


i am getting ready for the cr release, feel free to reopen if this is still a problem

> Class Cast exception in ConfigInfoElement.getConfigInfoElements() 
> ------------------------------------------------------------------
>
>                 Key: GPD-130
>                 URL: http://jira.jboss.com/jira/browse/GPD-130
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>
> ConfigInfoElement.getConfigInfoElements() always throws a class cast exception. The method is trying to cast from an object[] to a ConfigInfoElement[]. Instead we should cast each object in the array individually and copy it to the resultant array. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 06:00:50 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 8 Aug 2007 06:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8719812.1186567250539.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371431 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

ive added a few dependencies into the plugin so you'll only have to include the aop plugin in the pom file. im not sure if its possible to prevent the modules that the plugin depends on not to be included, but ill check it up.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 06:04:08 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:04:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25843504.1186567448284.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers closed GPD-78.
------------------------

    Resolution: Done

i am closing this again as i cannot see the exact problem. feel free to reopen if still a problem. also it would be good to attach a processdefinition producing the problem in that case

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  8 06:05:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 06:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-24) add convenient way to
 create loop transitions
In-Reply-To: <28729967.1168955216880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20993963.1186567549680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-24?page=all ]

Koen Aers updated GPD-24:
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
                       (was: jBPM JPDL Designer 3.1.0.CR)

> add convenient way to create loop transitions
> ---------------------------------------------
>
>                 Key: GPD-24
>                 URL: http://jira.jboss.com/jira/browse/GPD-24
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> the current workaround is to write the self-transition in xml.
> but this results in some *really* weird bendpoints when going back to the graphical 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 lists.jboss.org  Wed Aug  8 06:47:54 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 06:47:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30205959.1186570074975.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371443 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

Hi Koen,

I hope you don't think me rude for asking, can I email you directly with a couple of questions, I am implementing several large processes with JBPM JPDL for my company, they will be part of a project we are working on with British Airways, and I need a little help, I would hope not to take too much of your time, or perhaps you can suggest someone else who may be able to help ?  I only ask because although the forum is generally very good, I am waiting for an answer regarding mail and actors within eclipse 'http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115230', as I am not very clear on actors other than initiator.  I have two other questions which I could do with help on also.

Thanks for your time,

regards,

Ross

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 07:00:50 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 8 Aug 2007 07:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBWEB-88) Http11NioProtocol
 randomaly mix headers between requests
Message-ID: <18631260.1186570850236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-88?page=all ]

Thomas Diesler moved JBWS-1781 to JBWEB-88:
-------------------------------------------

              Project: JBoss Web  (was: JBoss Web Services)
                  Key: JBWEB-88  (was: JBWS-1781)
    Affects Version/s:     (was: jbossws-2.0.0)

> Http11NioProtocol randomaly mix headers between requests
> --------------------------------------------------------
>
>                 Key: JBWEB-88
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-88
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Running jbossws-2.0.0.GA on jboss 4.2, Redhat AS 4 update 4
>            Reporter: Tomer Cohen
>
> This version (as it relay on tomcat 6.0.10) suffer from http://issues.apache.org/bugzilla/show_bug.cgi?id=42701 which essentially makes the use of Nio useless.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 07:26:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1004)
 EJBRegistrationDeployer doesn't come up
In-Reply-To: <8824276.1183495011230.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21132280.1186572409312.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1004?page=all ]

Carlo de Wolf resolved EJBTHREE-1004.
-------------------------------------

    Resolution: Done

> EJBRegistrationDeployer doesn't come up
> ---------------------------------------
>
>                 Key: EJBTHREE-1004
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1004
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug  8 07:31:56 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:31:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-615) NPE in Embedded
 Jboss when getCallerPrincipal method on SessionContext
Message-ID: <31352589.1186572716244.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-615?page=all ]

Carlo de Wolf reassigned EJBTHREE-615:
--------------------------------------

    Assignee: Carlo de Wolf

> NPE in Embedded Jboss when getCallerPrincipal method on SessionContext
> ----------------------------------------------------------------------
>
>                 Key: EJBTHREE-615
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-615
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Nicolai ?dum
>         Assigned To: Carlo de Wolf
>         Attachments: BugReportInterceptor.java
>
>
> The bug is pretty easy to create.
> Modify the CalculaterBean in the security example that is distributed with JBoss embedded like this
> import javax.annotation.Resource;
> import java.security.Principal;
> import javax.ejb.SessionContext;
> ..
> public class CalculatorBean implements Calculator
> {
> @Resource SessionContext ctx;	
> @RolesAllowed({"student"})
> public int subtract(int x, int y)
> {
> Principal caller = ctx.getCallerPrincipal(); //Nullpointer
> return x - y;
> }
> The exception
> full stacktrace: 
> javax.ejb.EJBException: java.lang.NullPointerException 
> at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69) 
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83) 
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:167) 
> at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:100) 
> 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.localInvoke(StatelessContainer.java:181) 
> at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79) 
> at $Proxy15.getSubscriberDetails(Unknown Source) 
> Another user has reported that is is possible to get the principal from org.jboss.security.SecurityAssociation.getPrincipal(), but not from the Session 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 lists.jboss.org  Wed Aug  8 07:33:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:33:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-615) NPE in Embedded
 Jboss when getCallerPrincipal method on SessionContext
Message-ID: <21885055.1186572829667.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-615?page=all ]

Carlo de Wolf resolved EJBTHREE-615.
------------------------------------

    Resolution: Deferred

EJB 3 embedded is no longer supported.

> NPE in Embedded Jboss when getCallerPrincipal method on SessionContext
> ----------------------------------------------------------------------
>
>                 Key: EJBTHREE-615
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-615
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Nicolai ?dum
>         Assigned To: Carlo de Wolf
>         Attachments: BugReportInterceptor.java
>
>
> The bug is pretty easy to create.
> Modify the CalculaterBean in the security example that is distributed with JBoss embedded like this
> import javax.annotation.Resource;
> import java.security.Principal;
> import javax.ejb.SessionContext;
> ..
> public class CalculatorBean implements Calculator
> {
> @Resource SessionContext ctx;	
> @RolesAllowed({"student"})
> public int subtract(int x, int y)
> {
> Principal caller = ctx.getCallerPrincipal(); //Nullpointer
> return x - y;
> }
> The exception
> full stacktrace: 
> javax.ejb.EJBException: java.lang.NullPointerException 
> at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69) 
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83) 
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) 
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) 
> at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:167) 
> at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:100) 
> 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.localInvoke(StatelessContainer.java:181) 
> at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79) 
> at $Proxy15.getSubscriberDetails(Unknown Source) 
> Another user has reported that is is possible to get the principal from org.jboss.security.SecurityAssociation.getPrincipal(), but not from the Session 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 lists.jboss.org  Wed Aug  8 07:36:00 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-972)
 sessionContext.getBusinessObject(null) should throw IllegalStateException
In-Reply-To: <23520376.1179840652438.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13744084.1186572960473.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-972?page=all ]

Carlo de Wolf resolved EJBTHREE-972.
------------------------------------

    Resolution: Done

> sessionContext.getBusinessObject(null) should throw IllegalStateException
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-972
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-972
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug  8 07:45:49 2007
From: jira-events at lists.jboss.org (Shahad Ahmed (JIRA))
Date: Wed, 8 Aug 2007 07:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1067) Allow RuleAgent
 to take a RuleBaseConfiguration to configure the RuleBase it creates
Message-ID: <28877644.1186573549478.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow RuleAgent to take a RuleBaseConfiguration to configure the RuleBase it creates
------------------------------------------------------------------------------------

                 Key: JBRULES-1067
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1067
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Sun JRE 1.5_09
            Reporter: Shahad Ahmed
         Assigned To: Mark Proctor


Extend the API to allow a RuleAgent to use a  RuleBaseConfiguration object to configure the RuleBase it creates. For example, this will allow a user to specfiy options like Sequental mode etc when creating a RuleBase using a RuleAgent.

I know that you can set RuleBase options for all RuleBases by setting the appropriate System properties when calling the java VM, but it would be nice to be able to set these individually via the API for each RuleBase created using a RuleAgent. I guess this could be done fairly easily by adding an extra constructor(s) to RuleAgent that takes a RuleBaseConfiguration object -- rbConfig, say -- and in RuleAgent when it creates a new RuleBase instead of just using RulebaseFactory.newRuleBase() use RulebaseFactory.newRuleBase(rbConfig) 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 lists.jboss.org  Wed Aug  8 07:53:58 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:53:58 -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: <509158.1186574038602.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: AS 4.2.2.GA
                   EJB 3.0 RC11 - FD
                   AS 4.2.1.GA
                   AS 4.2.0 GA
                       (was: Branch_4_2)

Was already fixed.

> 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 RC11 - FD, AS 4.2.0 GA, AS 4.2.1.GA, AS 4.2.2.GA
>
>
> 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 lists.jboss.org  Wed Aug  8 07:53:58 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 07:53:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15232354.1186574038831.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-712?page=all ]

Carlo de Wolf resolved EJBTHREE-712.
------------------------------------

    Resolution: Done

> 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: AS 4.2.2.GA, EJB 3.0 RC11 - FD, AS 4.2.1.GA, AS 4.2.0 GA
>
>
> 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 lists.jboss.org  Wed Aug  8 08:07:49 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 08:07:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-989) Can't inject
 resources of type URL
In-Reply-To: <4013988.1181204294674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23804878.1186574869576.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-989?page=all ]

Carlo de Wolf resolved EJBTHREE-989.
------------------------------------

    Resolution: Done

> Can't inject resources of type URL
> ----------------------------------
>
>                 Key: EJBTHREE-989
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-989
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> All constructs leading into injection of an URL do not work.
> @Stateless
> @Remote(ResUrlChecker.class)
> @Resources({
>    @Resource(name="url3", type=java.net.URL.class, mappedName="http://localhost/url3")
> })
> public class ResUrlCheckerBean implements ResUrlChecker
> {
>    @Resource(mappedName="http://localhost")
>    private URL url1;
>    
>    // coming in via res-url
>    @Resource(name="url2")
>    private URL url2;
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 08:12:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 08:12:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25760596.1186575169446.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371463 ] 
            
Koen Aers commented on GPD-133:
-------------------------------

No please stick to the public user forum for these types of questions, they may be of interest to the entire community. If your questions are difficult to ask publicly for various reasons, consider a support contract or attending a public training.

Regards,
Koen

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 08:16:04 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 08:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-133) with two transitions
 from a node, both need to be labelled, or jbpm-console exceptions
In-Reply-To: <11120214.1186477706404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11731410.1186575364241.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-133?page=comments#action_12371465 ] 
            
Ross McDonald commented on GPD-133:
-----------------------------------

sure no problem,

Ross

> with two transitions from a node, both need to be labelled, or jbpm-console exceptions
> --------------------------------------------------------------------------------------
>
>                 Key: GPD-133
>                 URL: http://jira.jboss.com/jira/browse/GPD-133
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: osx, macbook pro, eclipse 3.3.0, tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>         Attachments: broken_process.xml, broken_process_exception.txt, fixed_process.xml
>
>
> when there are two transitions from a node, both need to be labelled (given a name), I am not sure if there is a validate xml option within the plugin, it would help if there was, if both are not given a name, the jbpm-console exceptions across multiple pages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 08:24:50 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 08:24:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-847) exception during
 destroy of
 stateful bean then @SecurityDomain is defined for seam bean
Message-ID: <30245751.1186575890089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-847?page=all ]

Carlo de Wolf resolved EJBTHREE-847.
------------------------------------

    Resolution: Rejected

You must also specify an unauthenticatedIdentity in your login-config.xml.

> exception during destroy of stateful bean then @SecurityDomain is defined for seam bean
> ---------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-847
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-847
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: jboss4.0.4GA+EJB3RC8+seam1.1.0.GA
>            Reporter: Ramil Israfilov
>         Assigned To: Carlo de Wolf
>
> With seam 1.1.0 we have an issue during destroying of bean. 
> Stateful bean is defined as
> @Stateful
> @SerializedConcurrentAccess
> @Scope(ScopeType.SESSION)
> @Name("studioAuditTracking")
> @Interceptors(SeamInterceptor.class)
> @SecurityDomain("OurDomain")
> public class StudioAuditTrackingBean implements Serializable, StudioAuditTracking 
> It works perfect, but during destroy there is an error. And log files full of such errors.
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) javax.ejb.EJBAccessException: Authentication failure
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:71)
> 2007-01-03 15:00:31,790 ERROR [STDERR] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) at
> I tried to set idleTimeoutSeconds to the same value like in web session timeout following WIKI, but still the same issue.
> it seems that security principal is not propagated during destroy. 
> after putting logging on debug level found the cause of an issue.
> Problem is that in tomcat separate thread is running to destroy expired sessions. But logon credentials are associated with another thread - which is served a connection from browser.
> So ContainerBackgroundProcessor[StandardEngine[jboss.web]]: is expiring session and calling seamListener.sessionDestroyed().
> which is trying to destroy bean which is protected by @SecurityDomain annotation. SecurityInterceptor tries to find principal - doesn't find it and do login() with null credentials (because this thread doesn't have associated credentials). And exception occurs. See debug logging below: 
> 2007-01-26 11:23:43,493 639138 DEBUG [org.apache.catalina.session.ManagerBase] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Start expire sessions StandardManager at 1169807023493 sessioncount 1
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Lifecycle] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) End of session, destroying contexts
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Lifecycle] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying conversation contexts: []
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Lifecycle] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying session context
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preDestroyContext.SESSION
> 2007-01-26 11:23:43,494 639139 DEBUG [org.jboss.seam.contexts.Contexts] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying: locale
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.contexts.Contexts] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) destroying: studioErrorTracking
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preDestroy.studioErrorTracking
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preSetVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,500 639145 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.postSetVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,514 639159 WARN [be.certipost.am.utils.loginmodule.AMBasedLoginModule] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Password was null and has been set to empty String!!!
> 2007-01-26 11:23:43,542 639187 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Level, false)
> 2007-01-26 11:23:43,542 639187 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,542 639187 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Level)
> 2007-01-26 11:23:43,543 639188 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,543 639188 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Logger, false)
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Logger)
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,548 639193 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,553 639198 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Category, false)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Category)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Priority, false)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Priority)
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,554 639199 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Level, false)
> 2007-01-26 11:23:43,570 639215 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,570 639215 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Level)
> 2007-01-26 11:23:43,571 639216 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,571 639216 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,571 639216 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.logging.XLevel, false)
> 2007-01-26 11:23:43,582 639227 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,582 639227 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.logging.XLevel)
> 2007-01-26 11:23:43,583 639228 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,583 639228 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,583 639228 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Logger, false)
> 2007-01-26 11:23:43,594 639239 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,594 639239 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Logger)
> 2007-01-26 11:23:43,594 639239 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,595 639240 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,595 639240 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.apache.log4j.Priority, false)
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.apache.log4j.Priority)
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,612 639257 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,613 639258 DEBUG [be.certipost.am.utils.jboss.Utils] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) flushing principal null for security domain CertiOne
> 2007-01-26 11:23:43,613 639258 DEBUG [be.certipost.am.utils.jboss.Utils] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Flushing principal for user null for security domain CertiOne on server 10.100.204.101
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.LinkRef, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.Reference, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.util.Vector, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.StringRefAddr, false)
> 2007-01-26 11:23:43,635 639280 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.naming.RefAddr, false)
> 2007-01-26 11:23:43,650 639295 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.adaptor.rmi.RMIAdaptor, false)
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.adaptor.rmi.RMIAdaptor)
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,651 639296 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,660 639305 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.adaptor.rmi.RMIAdaptorExt, false)
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,661 639306 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,663 639308 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.io.IOException, false)
> 2007-01-26 11:23:43,663 639308 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ReflectionException, false)
> 2007-01-26 11:23:43,663 639308 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.InstanceNotFoundException, false)
> 2007-01-26 11:23:43,664 639309 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.IntrospectionException, false)
> 2007-01-26 11:23:43,664 639309 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.MBeanRegistrationException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.MBeanException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.InvalidAttributeValueException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.AttributeNotFoundException, false)
> 2007-01-26 11:23:43,671 639316 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ListenerNotFoundException, false)
> 2007-01-26 11:23:43,672 639317 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.NotCompliantMBeanException, false)
> 2007-01-26 11:23:43,677 639322 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.InstanceAlreadyExistsException, false)
> 2007-01-26 11:23:43,679 639324 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ObjectName, false)
> 2007-01-26 11:23:43,680 639325 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.AttributeList, false)
> 2007-01-26 11:23:43,680 639325 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.ObjectInstance, false)
> 2007-01-26 11:23:43,680 639325 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.NotificationListener, false)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.NotificationFilter, false)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.adaptor.rmi.RMINotificationListener, false)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.adaptor.rmi.RMINotificationListener)
> 2007-01-26 11:23:43,683 639328 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.Attribute, false)
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.MBeanInfo, false)
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(javax.management.QueryExp, false)
> 2007-01-26 11:23:43,689 639334 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.util.Set, false)
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.ClientContainer, false)
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.ClientContainer)
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,696 639341 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.ClientMethodInterceptor, false)
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.ClientMethodInterceptor)
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,701 639346 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.Interceptor, false)
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.Interceptor)
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.proxy.SecurityInterceptor, false)
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,707 639352 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.proxy.SecurityInterceptor)
> 2007-01-26 11:23:43,708 639353 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,708 639353 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,708 639353 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor, false)
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor)
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,715 639360 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.InvokerInterceptor, false)
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.InvokerInterceptor)
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,727 639372 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.id.GUID, false)
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.id.GUID)
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,739 639384 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.id.UID, false)
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.id.UID)
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,757 639402 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.id.VMID, false)
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.id.VMID)
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,769 639414 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.util.platform.PID, false)
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.util.platform.PID)
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,781 639426 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.InvocationContext, false)
> 2007-01-26 11:23:43,792 639437 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.InvocationContext)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.util.HashMap, false)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.InvocationKey, false)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.InvocationKey)
> 2007-01-26 11:23:43,793 639438 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,794 639439 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,794 639439 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy, false)
> 2007-01-26 11:23:43,796 639441 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,796 639441 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy)
> 2007-01-26 11:23:43,796 639441 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,797 639442 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,802 639447 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(org.jboss.invocation.jrmp.server.JRMPInvoker_Stub, false)
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Searching local repositories
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) findClass(org.jboss.invocation.jrmp.server.JRMPInvoker_Stub)
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Delegating to parent classloader at end: java.net.FactoryURLClassLoader at 6403b70c
> 2007-01-26 11:23:43,803 639448 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Loading class from parent
> 2007-01-26 11:23:43,812 639457 DEBUG [org.apache.catalina.loader.WebappClassLoader] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) loadClass(java.lang.Number, false)
> 2007-01-26 11:23:43,831 639476 DEBUG [be.certipost.am.utils.jboss.Utils] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) DONE Flushing principal for user null for security domain CertiOne on server 10.100.204.101
> 2007-01-26 11:23:43,835 639480 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preRemoveVariable.studioErrorTracking
> 2007-01-26 11:23:43,835 639480 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.postRemoveVariable.studioErrorTracking
> 2007-01-26 11:23:43,835 639480 DEBUG [org.jboss.seam.interceptors.RemoveInterceptor] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Stateful component was removed: studioErrorTracking
> 2007-01-26 11:23:43,839 639484 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.preRemoveVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,839 639484 DEBUG [org.jboss.seam.core.Events] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Processing event:org.jboss.seam.postRemoveVariable.org.jboss.seam.outermostExceptionInterceptor
> 2007-01-26 11:23:43,840 639485 WARN [org.jboss.seam.contexts.Contexts] (node1) (ContainerBackgroundProcessor[StandardEngine[jboss.web]]:) Could not destroy component: studioErrorTracking
> javax.ejb.EJBAccessException: Authentication failure
> at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
> at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:71)
> 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.stateful.StatefulContainer.localInvoke(StatefulContainer.java:188)
> at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:98)
> at $Proxy350.stop(Unknown Source)
> at be.certipost.gui.studio.tracking.beans.ErrorTracking$$FastClassByCGLIB$$51bd700e.invoke()
> at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
> at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:73)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:55)
> at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:39)
> 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.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
> at org.jboss.seam.interceptors.ExceptionInterceptor.handleExceptions(ExceptionInterceptor.java:38)
> at sun.reflect.GeneratedMethodAccessor145.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
> at org.jboss.seam.interceptors.SynchronizationInterceptor.serialize(SynchronizationInterceptor.java:30)
> at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
> at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
> at org.jboss.seam.intercept.RootInterceptor.createSeamInvocationContext(RootInterceptor.java:144)
> at org.jboss.seam.intercept.RootInterceptor.invokeInContexts(RootInterceptor.java:129)
> at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:102)
> at org.jboss.seam.intercept.ClientSideInterceptor.interceptInvocation(ClientSideInterceptor.java:82)
> at org.jboss.seam.intercept.ClientSideInterceptor.intercept(ClientSideInterceptor.java:51)
> at org.jboss.seam.intercept.Proxy$$EnhancerByCGLIB$$4b2b9a98.stop()
> 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.seam.util.Reflections.invoke(Reflections.java:18)
> at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:102)
> at org.jboss.seam.Component.callComponentMethod(Component.java:1791)
> at org.jboss.seam.Component.callDestroyMethod(Component.java:1747)
> at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:189)
> at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:230)
> at org.jboss.seam.servlet.SeamListener.sessionDestroyed(SeamListener.java:45)
> at org.apache.catalina.session.StandardSession.expire(StandardSession.java:687)
> at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:579)
> at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:678)
> at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:663)
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1284)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1569)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578)
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1558)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.auth.login.LoginException: be.certipost.am.InvalidUsernameException: Invalid username: null
> at be.certipost.am.utils.loginmodule.AMBasedLoginModule.login(AMBasedLoginModule.java:146)
> at be.certipost.certione.loginmodule.CertioneAMBasedLoginModule.login(CertioneAMBasedLoginModule.java:56)
> 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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
> at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:601)
> at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535)
> at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
> at org.jboss.aspects.security.AuthenticationInterceptor.authenticate(AuthenticationInterceptor.java:121)
> at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:67)
> ... 61 more
> Caused by: be.certipost.am.InvalidUsernameException: Invalid username: null
> at be.certipost.am.bl.AuthenticationBLBean.authenticate(AuthenticationBLBean.java:54)
> at sun.reflect.GeneratedMethodAccessor410.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.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
> at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
> 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 $Proxy523.authenticate(Unknown Source)
> 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 be.certipost.am.utils.blfactory.AMBLFactory$AuthenticationBLProxyHandler.invoke(AMBLFactory.java:154)
> at $Proxy524.authenticate(Unknown Source)
> at be.certipost.am.utils.loginmodule.AMBasedLoginModule.loginWithPassword(AMBasedLoginModule.java:176)
> at be.certipost.am.utils.loginmodule.AMBasedLoginModule.login(AMBasedLoginModule.java:118)
> ... 77 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 lists.jboss.org  Wed Aug  8 08:44:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 08:44:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-137) problem configuriing
 exception class
Message-ID: <7080582.1186577089238.JavaMail.jira@cloud.prod.atl2.jboss.com>

problem configuriing exception class
------------------------------------

                 Key: GPD-137
                 URL: http://jira.jboss.com/jira/browse/GPD-137
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
            Reporter: Koen Aers
         Assigned To: Koen Aers
             Fix For: jBPM JPDL Designer 3.1.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 09:04:04 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 09:04:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-138) error dialogue appears
 on task panel of properties for task node
Message-ID: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>

error dialogue appears on task panel of properties for task node
----------------------------------------------------------------

                 Key: GPD-138
                 URL: http://jira.jboss.com/jira/browse/GPD-138
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
         Environment: os x macbok pro, eclipse 3.3.0
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Minor


Hi,

when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :

Reason:
0

'An error has occurred. See error log for more details.
0

On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 09:46:49 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 09:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
Message-ID: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>

CacheInvalidator.areInvalid doesn't lock partitions
---------------------------------------------------

                 Key: JBAS-4597
                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1


org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 10:02:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Wed, 8 Aug 2007 10:02:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1029) Can't use JMock
 to mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31972842.1186581769535.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1029?page=all ]

John Doe resolved JBRULES-1029.
-------------------------------

    Fix Version/s:  4.0.0.GA
                       (was: 4.0.1)
       Resolution: Done

After I moved classes to package test.drools and changed rule as

package sample;

import test.drools.ResultsInterface;
import test.drools.ContentStorageInterface;
import test.drools.RuleHelper;

rule "Verify_1"
    when
	content : ContentStorageInterface()
	results : ResultsInterface( resultsCount > 0) 
	    from RuleHelper.search(content,"pattern","column")
    then
	System.out.println( results ); 
end

everything compiled and at least test was passed.

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For:  4.0.0.GA
>
>         Attachments: drools.zip
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 10:04:49 2007
From: jira-events at lists.jboss.org (John Doe (JIRA))
Date: Wed, 8 Aug 2007 10:04:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1029) Can't use JMock to
	mimic facts
In-Reply-To: <22845977.1185375407315.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25750642.1186581889377.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1029?page=all ]

John Doe closed JBRULES-1029.
-----------------------------


fixed in trunk?

> Can't use JMock to mimic facts
> ------------------------------
>
>                 Key: JBRULES-1029
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1029
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: java version "1.5.0_11-p5"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-p5-root_04_jul_2007_17_12)
> Java HotSpot(TM) Client VM (build 1.5.0_11-p5-root_04_jul_2007_13_39, mixed mode)
>            Reporter: John Doe
>         Assigned To: Edson Tirelli
>             Fix For:  4.0.0.GA
>
>         Attachments: drools.zip
>
>
> It is not possible to use objects, created by JMock, to assert into working memory, below is the test case:
> ===============================================
> /**
>  * Defines methods used to access underlying storage
>  */
> public interface ContentStorageInterface {
>     public ResultsInterface search(QueryInterface query);
> }
> ===============================================
> /**
>  * Implementation of searching for Lucene 
>  */
> public class LuceneQuery implements QueryInterface {
>     public LuceneQuery(String query, String field) {
>     }
>     /**
>      * @see java.lang.Object#equals(java.lang.Object)
>      */
>     @Override
>     public boolean equals(Object obj) {
>         if (obj == this)
>             return true;
>         if (!(obj instanceof LuceneQuery))
>             return false;
>         return true;
>     }
> }
> ===============================================
> /**
>  * Defines methods to use for searching
>  */
> public interface QueryInterface {
> }
> ===============================================
> import java.util.Iterator;
> /**
>  * Defines methods to use for managing search results
>  */
> public interface ResultsInterface {
>     public int getResultsCount();
>     public Iterator<Object> getResults();
> }
> ===============================================
> /**
>  * Defines helper methods for using in rules
>  */
> public class RuleHelper {
>     public static final ResultsInterface search(
>             ContentStorageInterface content, String pattern, String column) {
>         return content.search(new LuceneQuery(pattern, column));
>     }
> }
> ===============================================
> package sample;
> rule "Verify_1"
>     when
>         content : ContentStorageInterface()
>         results : ResultsInterface( resultsCount > 0)
>             from RuleHelper.search(content,"pattern","column")
>     then
>         System.out.println( results );
> end
> ===============================================
> import java.io.FileReader;
> import java.io.Reader;
> import junit.framework.TestCase;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.DrlParser;
> import org.drools.compiler.PackageBuilder;
> import org.drools.lang.descr.PackageDescr;
> import org.drools.rule.Package;
> import org.jmock.Expectations;
> import org.jmock.Mockery;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class BasicRuleFlowTest extends TestCase {
>     Mockery context = new Mockery();
>     public void testGenericFlow() throws Exception {
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader(("SampleSearchRule.drl"));
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>         RuleBase base = RuleBaseFactory.newRuleBase();
>         base.addPackage(pkg);
>         WorkingMemory memory = base.newStatefulSession();
>         final ContentStorageInterface storage = context
>                 .mock(ContentStorageInterface.class);
>         context.checking(new Expectations() {
>             {
>                 one(storage).search(new LuceneQuery("", ""));
>             }
>         });
>         memory.insert(storage);
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 10:26:49 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 10:26:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
In-Reply-To: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27661322.1186583209407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4597?page=all ]

Alexey Loubyansky updated JBAS-4597:
------------------------------------

    Fix Version/s: JBossAS-4.0.5.SP1 

> CacheInvalidator.areInvalid doesn't lock partitions
> ---------------------------------------------------
>
>                 Key: JBAS-4597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-3.2.8.SP1, JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.SP1 ,  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1
>
>
> org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 10:50:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 8 Aug 2007 10:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1028) Lazy transaction
 enlistment is not working
Message-ID: <2588803.1186584602584.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lazy transaction enlistment is not working
------------------------------------------

                 Key: EJBTHREE-1028
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1028
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf
             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug  8 11:01:04 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 11:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-137) problem configuriing
 exception class
In-Reply-To: <7080582.1186577089238.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12020536.1186585264421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-137?page=all ]

Koen Aers updated GPD-137:
--------------------------

    Component/s: jpdl

> problem configuriing exception class
> ------------------------------------
>
>                 Key: GPD-137
>                 URL: http://jira.jboss.com/jira/browse/GPD-137
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 11:06:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 11:06:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-138) error dialogue appears
 on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2016898.1186585609565.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-138?page=all ]

Koen Aers closed GPD-138.
-------------------------

    Resolution: Cannot Reproduce Bug

I could not reproduce this on the current head. Can you verify if the problem also exists in today's release and reopen if necessary?

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 11:10:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 11:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20375432.1186585849352.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371499 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

hi, sorry today's release of what, the plugin or Eclipse ?

cheers

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 11:18:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 8 Aug 2007 11:18:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9674334.1186586329380.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371501 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

of the plugin... it is the release candidate before the final that is supposed to be released next week.

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 11:34:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 8 Aug 2007 11:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14052660.1186587289367.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371504 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

ah ok, I will check first thing tomorrow morning, just off to a meeting now till end of play today

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug  8 12:47:49 2007
From: jira-events at lists.jboss.org (liz ch (JIRA))
Date: Wed, 8 Aug 2007 12:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1035) CLONE -deploy a
 process archive documentation incorrect
Message-ID: <4397147.1186591669572.JavaMail.jira@cloud.prod.atl2.jboss.com>

CLONE -deploy a process archive documentation incorrect
-------------------------------------------------------

                 Key: JBPM-1035
                 URL: http://jira.jboss.com/jira/browse/JBPM-1035
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Documentation
    Affects Versions: jBPM 3.0.2
            Reporter: liz ch
         Assigned To: Tom Baeyens


Under section 13.1.1 - Deploying a proceses archive:

The code sample for  target name="deploy.par" is incorrect:  The task definition rg.jbpm.jpdl.par.ProcessArchiveDeployerTask should be org.jbpm.ant.DeployParTask

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 13:13:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-675) Able to kill and
 suspend a process or token that has ended
Message-ID: <29988787.1186593182520.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-675?page=comments#action_12371509 ] 
            
Ronald van Kuijk commented on JBPM-675:
---------------------------------------

works on 3.2, should this still be fixed in 3.1? I assign it to 3.1.5, and see what happens

> Able to kill and suspend a process or token that has ended
> ----------------------------------------------------------
>
>                 Key: JBPM-675
>                 URL: http://jira.jboss.com/jira/browse/JBPM-675
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>         Environment: Mac OS X 10.4.6 Java 1.4.2_09
>            Reporter: michaelklem
>         Assigned To: Tom Baeyens
>            Priority: Trivial
>             Fix For: jBPM 3.1.5
>
>
> When a process instance or token has ended, I can still call the suspend, resume and kill APIs on that process instance or token without an exception being thrown. IMO an exception should be thrown to indicate that these APIs are used in an illegal 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 lists.jboss.org  Wed Aug  8 13:13:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-675) Able to kill and
 suspend a process or token that has ended
Message-ID: <7256345.1186593182719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-675?page=all ]

Ronald van Kuijk updated JBPM-675:
----------------------------------

        Fix Version/s: jBPM 3.1.5
    Affects Version/s:     (was: jBPM 3.1.1)

> Able to kill and suspend a process or token that has ended
> ----------------------------------------------------------
>
>                 Key: JBPM-675
>                 URL: http://jira.jboss.com/jira/browse/JBPM-675
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>         Environment: Mac OS X 10.4.6 Java 1.4.2_09
>            Reporter: michaelklem
>         Assigned To: Tom Baeyens
>            Priority: Trivial
>             Fix For: jBPM 3.1.5
>
>
> When a process instance or token has ended, I can still call the suspend, resume and kill APIs on that process instance or token without an exception being thrown. IMO an exception should be thrown to indicate that these APIs are used in an illegal 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 lists.jboss.org  Wed Aug  8 13:14:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:14:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-675) Able to kill and
 suspend a process or token that has ended
Message-ID: <19490451.1186593289663.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-675?page=all ]

Ronald van Kuijk updated JBPM-675:
----------------------------------

    Affects Version/s: jBPM 3.1.1

> Able to kill and suspend a process or token that has ended
> ----------------------------------------------------------
>
>                 Key: JBPM-675
>                 URL: http://jira.jboss.com/jira/browse/JBPM-675
>             Project: JBoss jBPM
>          Issue Type: Patch
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Mac OS X 10.4.6 Java 1.4.2_09
>            Reporter: michaelklem
>         Assigned To: Tom Baeyens
>            Priority: Trivial
>             Fix For: jBPM 3.1.5
>
>
> When a process instance or token has ended, I can still call the suspend, resume and kill APIs on that process instance or token without an exception being thrown. IMO an exception should be thrown to indicate that these APIs are used in an illegal 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 lists.jboss.org  Wed Aug  8 13:50:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 13:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-789) Release 2.2.1.SP1
Message-ID: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release 2.2.1.SP1
-----------------

                 Key: JBREM-789
                 URL: http://jira.jboss.com/jira/browse/JBREM-789
             Project: JBoss Remoting
          Issue Type: Release
      Security Level: Public (Everyone can see)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 13:50:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 13:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23574019.1186595449583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

        Fix Version/s: 2.2.1.SP1
    Affects Version/s: 2.2.1.SP1

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.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 lists.jboss.org  Wed Aug  8 13:52:49 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 8 Aug 2007 13:52:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1035) CLONE -deploy a
 process archive documentation incorrect
In-Reply-To: <4397147.1186591669572.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26754020.1186595569459.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1035?page=all ]

Ronald van Kuijk closed JBPM-1035.
----------------------------------

    Resolution: Won't Fix

3.0.2 docs will not be updated anymore

> CLONE -deploy a process archive documentation incorrect
> -------------------------------------------------------
>
>                 Key: JBPM-1035
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1035
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: jBPM 3.0.2
>            Reporter: liz ch
>         Assigned To: Tom Baeyens
>
> Under section 13.1.1 - Deploying a proceses archive:
> The code sample for  target name="deploy.par" is incorrect:  The task definition rg.jbpm.jpdl.par.ProcessArchiveDeployerTask should be org.jbpm.ant.DeployParTask

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 13:59:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Wed, 8 Aug 2007 13:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-111) Add ability to
 forward and reverse
 map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11479079.1186595989420.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Matthew Sandoz reopened GPD-111:
--------------------------------

             
sorry to have to reopen this but there are several use cases and the one i overlooked yesterday isnt working. 

when i create a node from the palette, the createAdapterFromModel method of the XmlAdapterFactory is called. At the end of this, the factory calls createAdapterFromElementName. Unfortunately this doesnt allow the factory to create an adapter specific to the SemanticElement, but rather the node name. The node name is shared among many classes and so always returns the same adapter.

I was able to get around this as in my original code by adding the following into the createAdapterFromModel method:

		INodeNotifier element = (INodeNotifier)document.createElement(elementName);
		XmlAdapter result;
		try {
			result = (XmlAdapter) configurationElement.createExecutableExtension("adapterClass");
			result.setNode((Node)element);
			result.setFactory(this);
			return result;
		} catch (CoreException e) {
			Logger.logError("Unable to create XML Adapter for " + jpdlElement.getElementId(), e);
		}

right before the final return. 

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:12:16 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:12:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1024) Distributed
 queue stops working when node is killed
Message-ID: <3119231.1186596736249.JavaMail.jira@cloud.prod.atl2.jboss.com>

Distributed queue stops working when node is killed
---------------------------------------------------

                 Key: JBMESSAGING-1024
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1024
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


If start a test with 3 nodes, then kill one of them then the distributed queue doesn't work.

Try starting DistributedRequestResponseTest with 3 nodes then killing to replicate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:19:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1025) Add test in
 GroupManagementTest
Message-ID: <24748680.1186597189354.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add test in GroupManagementTest
-------------------------------

                 Key: JBMESSAGING-1025
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1025
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


.... that tests that failover map is created in vew order

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:19:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases, also DB2
Message-ID: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ensure successfull test run against all supported databases, also DB2
---------------------------------------------------------------------

                 Key: JBMESSAGING-1026
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:21:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:21:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1027) Client
	updating fails
Message-ID: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Client updating fails
---------------------

                 Key: JBMESSAGING-1027
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Client side node list updating currently only occurs if there is an active connection on the connection factory.

This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:23:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1028) Cleanup
 groupmember startup
Message-ID: <20025793.1186597429469.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cleanup groupmember startup
---------------------------

                 Key: JBMESSAGING-1028
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1028
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Cleanup the group member startup so we ensure that view change precedes state arrival precedes messages.

Add sanity checks to ensure this is the 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 lists.jboss.org  Wed Aug  8 14:25:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:25:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1029) Deadlock in
 messaging postoffice
Message-ID: <28783104.1186597549324.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock in messaging postoffice
--------------------------------

                 Key: JBMESSAGING-1029
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1029
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:27:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1030) Updated JBM
 to use new patched JBoss remoting jar
Message-ID: <11490984.1186597669494.JavaMail.jira@cloud.prod.atl2.jboss.com>

Updated JBM to use new patched JBoss remoting jar
-------------------------------------------------

                 Key: JBMESSAGING-1030
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1030
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Update JBM to use new patched jar which resolves all known remoting 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 lists.jboss.org  Wed Aug  8 14:27:49 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Wed, 8 Aug 2007 14:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11455958.1186597669669.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371517 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

i will attach a file with the changes as this solution doesnt seem to be perfect yet.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:31:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:31:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1031) Potential bug
 in cancelling delivery
Message-ID: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>

Potential bug in cancelling delivery
------------------------------------

                 Key: JBMESSAGING-1031
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:34:04 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:34:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1032) Problem with
 bridge when source is remote
Message-ID: <25187402.1186598044726.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem with bridge when source is remote
-----------------------------------------

                 Key: JBMESSAGING-1032
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1032
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Need to investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:37:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:37:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1033) Rationalise
 and speedup test suite
Message-ID: <9387617.1186598269311.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rationalise and speedup test suite
----------------------------------

                 Key: JBMESSAGING-1033
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1033
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


After migration to Hudson - the test takes far too long to run.

It needs to be speeded up if it is to be any use.

The clustering, bridge and thirdparty tests do not need to be run against all databases, only the invm and remote tests 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 lists.jboss.org  Wed Aug  8 14:39:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1034) Allow
 connection factories to be created programmatically
Message-ID: <9067157.1186598389285.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow connection factories to be created programmatically
---------------------------------------------------------

                 Key: JBMESSAGING-1034
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1034
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 1


We should allow connection factories to be created programmatically on the client side - this allows people to use JBM when they don't have JNDI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:42:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1035) Potential
	security issue
Message-ID: <6455963.1186598569318.JavaMail.jira@cloud.prod.atl2.jboss.com>

Potential security issue
------------------------

                 Key: JBMESSAGING-1035
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1035
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Need to investigate whether there is an issue here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 14:46:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:46:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1036) Consider
 createing JBossDestination interface
Message-ID: <10696945.1186598809453.JavaMail.jira@cloud.prod.atl2.jboss.com>

Consider createing JBossDestination interface
---------------------------------------------

                 Key: JBMESSAGING-1036
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1036
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


To solve forum 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 lists.jboss.org  Wed Aug  8 14:56:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 14:56:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1014) Look at
	JGroups anycast
In-Reply-To: <9508348.1184347872500.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31587419.1186599409354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1014?page=all ]

Tim Fox updated JBMESSAGING-1014:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Look at JGroups anycast
> -----------------------
>
>                 Key: JBMESSAGING-1014
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1014
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> To avoid issue with having to multicast even when there is only one subscriber

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 16:17:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Wed, 8 Aug 2007 16:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18175299.1186604269751.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371539 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Hi again

All the dependencies that I am supposed to have in the application at runtime I want to specify as dependencies.
Pleazze make no no hidden things here....

I know very little about the AOP, but if I am supposed to use i.e. the <concurrent> artifact I understand I have to add it and I want to do so. 

My claim goes on the artifacts that the plugin uses to run the plugin at compile time. These artifacts should NOT become part of the runtime.

If you make the plugin in a way that the plugin ends up managing runtime artifacts I think it is BAD. Then you will need to issue a new version of the plugin each time the AOP / Jboss-server changes anything.


> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 16:19:54 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Wed, 8 Aug 2007 16:19:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17825499.1186604394021.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371540 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

ok this appears to be working now - heres a patch from eclipse from the eclipse "Create Patch" - is that the best way to provide these? if not i can attach the entire file...

### Eclipse Workspace Patch 1.0
#P org.jbpm.gd.jpdl
Index: src/org/jbpm/gd/common/xml/XmlAdapterFactory.java
===================================================================
RCS file: /cvsroot/jbpm/jbpm.3/designer/jpdl/org.jbpm.gd.jpdl/src/org/jbpm/gd/common/xml/XmlAdapterFactory.java,v
retrieving revision 1.8
diff -u -r1.8 XmlAdapterFactory.java
--- src/org/jbpm/gd/common/xml/XmlAdapterFactory.java	7 Aug 2007 13:02:45 -0000	1.8
+++ src/org/jbpm/gd/common/xml/XmlAdapterFactory.java	8 Aug 2007 20:16:40 -0000
@@ -99,6 +99,17 @@
 					Logger.logError("Neither xmlElement nor nameProvider are present on mapping configuration element for " + jpdlElement.getElementId(), e);
 				}
 			}
+		} else {
+			try {
+				XmlAdapter adapter = (XmlAdapter) configurationElement.createExecutableExtension("adapterClass");
+				INodeNotifier element = (INodeNotifier)document.createElement(elementName);
+				element.addAdapter(adapter);
+				adapter.setNode((Node)element);
+				adapter.setFactory(this);
+				return adapter;
+			} catch (CoreException e) {
+				Logger.logError("Unable to create XML Adapter for " + jpdlElement.getElementId(), e);
+			}
 		}
 		return elementName == null ? null : createAdapterFromElementName(elementName);
 	}



> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 16:32:49 2007
From: jira-events at lists.jboss.org (Michael Newcomb (JIRA))
Date: Wed, 8 Aug 2007 16:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-571) all threads are daemon
Message-ID: <20660552.1186605169499.JavaMail.jira@cloud.prod.atl2.jboss.com>

all threads are daemon
----------------------

                 Key: JGRP-571
                 URL: http://jira.jboss.com/jira/browse/JGRP-571
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
            Reporter: Michael Newcomb
         Assigned To: Bela Ban


Create and join a channel, then LockSupport.park() in main.
Dump out all Threads (ctrl-break) and they are all daemon.

Thread Pool threads get marked daemon because they are created from the IO threads (which are daemon).

Recommend searching for setDaemon(true) and determining if all uses are correct.

Caused my program (which is event/message driven) to immediately exit.

"Incoming Thread,137.161.130.87:1956" daemon prio=10 tid=0x033ad400 nid=0x2378 waiting on condition [0x040cf000..0x040cfc94]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x24107308> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
	at java.lang.Thread.run(Thread.java:619)

"MERGE2.FindSubgroups thread (channel=iewtpt, local_addr=137.161.130.87:1956)" daemon prio=6 tid=0x033a9800 nid=0xe70 waiting on condition [0x0407f000..0x0407fd14]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at org.jgroups.util.Util.sleep(Util.java:851)
	at org.jgroups.protocols.MERGE2$FindSubgroups.run(MERGE2.java:265)
	at java.lang.Thread.run(Thread.java:619)

"OOB Thread,137.161.130.87:1956" daemon prio=10 tid=0x0337b400 nid=0x24bc waiting on condition [0x0411f000..0x0411fd94]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x241000f0> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
	at java.lang.Thread.run(Thread.java:619)

"ServerSocket acceptor thread (channel=iewtpt)" daemon prio=6 tid=0x033a8800 nid=0x1e38 runnable [0x0402f000..0x0402fb14]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
	- locked <0x24100258> (a java.net.SocksSocketImpl)
	at java.net.ServerSocket.implAccept(ServerSocket.java:450)
	at java.net.ServerSocket.accept(ServerSocket.java:421)
	at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:1073)
	at java.lang.Thread.run(Thread.java:619)

"UDP mcast receiver,137.161.130.87:1956" daemon prio=10 tid=0x0303ec00 nid=0x2170 runnable [0x03fdf000..0x03fdfc14]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
	- locked <0x24100458> (a java.net.DatagramPacket)
	- locked <0x24100478> (a java.net.MulticastSocket)
	at org.jgroups.protocols.UDP.run(UDP.java:247)
	at java.lang.Thread.run(Thread.java:619)

"UDP ucast receiver,137.161.130.87:1956" daemon prio=6 tid=0x02ff3000 nid=0x2734 runnable [0x03f8f000..0x03f8fb94]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
	- locked <0x241006c0> (a java.net.DatagramPacket)
	- locked <0x241006e0> (a java.net.DatagramSocket)
	at org.jgroups.protocols.UDP$UcastReceiver.run(UDP.java:916)
	at java.lang.Thread.run(Thread.java:619)

"main" prio=6 tid=0x001ca000 nid=0x208 waiting on condition [0x002af000..0x002afe54]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283)
	at HostNode.main(HostNode.java:607)
	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:17:49 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-272) allow xpath
 expression/query to create more than one occurrence of an element
In-Reply-To: <21460509.1185436907082.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6209133.1186607869788.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-272?page=comments#action_12371547 ] 
            
Alejandro Guizar commented on BPEL-272:
---------------------------------------

Thanks for the reference. However, as far as I can see, the extension function has no advantages over the "last plus one" predicate. Both compromise the portability of the process definition. 

On the other hand, the extension function has one clear disadvantage. Consider the signature:

addChildNode(Element e, Node childNode)

To implement it, the element e must be cloned, the childNode appended to the clone, and the whole thing copied to the destination. In consequence, the function above has time and space requirements proportional to the size of the array. The "last plus one" predicate, while somewhat dirty, has constant performance.

An alternate,cleaner approach is to leverage the <bpel2:extensionAssignOperation> construct. Apart from the standard <bpel2:copy> we could offer a <jbpm:append> operation to perform this exact manipulation without abusing XPath syntax or introducing a function of linear performance. 

Unfortunately there is no <extensionAssignOperation> construct in BPEL 1.1, which is what prevented me from proposing this approach in the first place. There is a workaround, though: <jbpm:append> elements can appear directly under the <bpel11:assign> element.

> allow xpath expression/query to create more than one occurrence of an element
> -----------------------------------------------------------------------------
>
>                 Key: BPEL-272
>                 URL: http://jira.jboss.com/jira/browse/BPEL-272
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The current XPath sublanguage implementation automatically creates nodes missing from location paths during assignment. This facility has a number of conceptual limitations. One of them is the inability to append a child element to an existing element if the latter already has a child element with the same name. There is no XPath syntax to express that a new element is required!
> It is tempting to think of a numeric XPath predicate as an array index, leading to the next snippet:
> <copy>
>  <from><literal>haha</literal></from>
>  <to variable='laughter' xmlns:ex='http://jbpm.org/bpel/examples'>
>   <query>ex:laugh[last() + 1]</query>
>  </to>
> </copy>
> However, such an interpretation of a predicate is wrong. Consider the following extract from XPath 1.0 specification on predicates:
> "A PredicateExpr is evaluated by evaluating the Expr and converting the result to a boolean. If the result is a number, the result will be converted to true if the number is equal to the context position and will be converted to false otherwise."
> The description of the last() function reads:
> "The last function returns a number equal to the context size from the expression evaluation context."
> Noticed the problem? The context position is never greater than the context size. Therefore the predicate [last() + 1] does not represent the position "one past the context size" but the boolean value false. Unfortunately, no other predicate seems appropriate. 
> PROPOSAL Introduce a minor deviation from the XPath 1.0 specification. Interpret the result of a numeric predicate that equals the context size plus one as a  request to create a new occurrence of the 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 lists.jboss.org  Wed Aug  8 17:19:49 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Aug 2007 17:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-571) all threads are daemon
In-Reply-To: <20660552.1186605169499.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <265215.1186607989414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-571?page=all ]

Bela Ban updated JGRP-571:
--------------------------

    Fix Version/s: 2.6

> all threads are daemon
> ----------------------
>
>                 Key: JGRP-571
>                 URL: http://jira.jboss.com/jira/browse/JGRP-571
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Michael Newcomb
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Create and join a channel, then LockSupport.park() in main.
> Dump out all Threads (ctrl-break) and they are all daemon.
> Thread Pool threads get marked daemon because they are created from the IO threads (which are daemon).
> Recommend searching for setDaemon(true) and determining if all uses are correct.
> Caused my program (which is event/message driven) to immediately exit.
> "Incoming Thread,137.161.130.87:1956" daemon prio=10 tid=0x033ad400 nid=0x2378 waiting on condition [0x040cf000..0x040cfc94]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x24107308> (a java.util.concurrent.SynchronousQueue$TransferStack)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
> 	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
> 	at java.lang.Thread.run(Thread.java:619)
> "MERGE2.FindSubgroups thread (channel=iewtpt, local_addr=137.161.130.87:1956)" daemon prio=6 tid=0x033a9800 nid=0xe70 waiting on condition [0x0407f000..0x0407fd14]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
> 	at java.lang.Thread.sleep(Native Method)
> 	at org.jgroups.util.Util.sleep(Util.java:851)
> 	at org.jgroups.protocols.MERGE2$FindSubgroups.run(MERGE2.java:265)
> 	at java.lang.Thread.run(Thread.java:619)
> "OOB Thread,137.161.130.87:1956" daemon prio=10 tid=0x0337b400 nid=0x24bc waiting on condition [0x0411f000..0x0411fd94]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x241000f0> (a java.util.concurrent.SynchronousQueue$TransferStack)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
> 	at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
> 	at java.lang.Thread.run(Thread.java:619)
> "ServerSocket acceptor thread (channel=iewtpt)" daemon prio=6 tid=0x033a8800 nid=0x1e38 runnable [0x0402f000..0x0402fb14]
>    java.lang.Thread.State: RUNNABLE
> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
> 	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
> 	- locked <0x24100258> (a java.net.SocksSocketImpl)
> 	at java.net.ServerSocket.implAccept(ServerSocket.java:450)
> 	at java.net.ServerSocket.accept(ServerSocket.java:421)
> 	at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:1073)
> 	at java.lang.Thread.run(Thread.java:619)
> "UDP mcast receiver,137.161.130.87:1956" daemon prio=10 tid=0x0303ec00 nid=0x2170 runnable [0x03fdf000..0x03fdfc14]
>    java.lang.Thread.State: RUNNABLE
> 	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> 	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
> 	- locked <0x24100418> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
> 	- locked <0x24100458> (a java.net.DatagramPacket)
> 	- locked <0x24100478> (a java.net.MulticastSocket)
> 	at org.jgroups.protocols.UDP.run(UDP.java:247)
> 	at java.lang.Thread.run(Thread.java:619)
> "UDP ucast receiver,137.161.130.87:1956" daemon prio=6 tid=0x02ff3000 nid=0x2734 runnable [0x03f8f000..0x03f8fb94]
>    java.lang.Thread.State: RUNNABLE
> 	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> 	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
> 	- locked <0x24100680> (a java.net.PlainDatagramSocketImpl)
> 	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
> 	- locked <0x241006c0> (a java.net.DatagramPacket)
> 	- locked <0x241006e0> (a java.net.DatagramSocket)
> 	at org.jgroups.protocols.UDP$UcastReceiver.run(UDP.java:916)
> 	at java.lang.Thread.run(Thread.java:619)
> "main" prio=6 tid=0x001ca000 nid=0x208 waiting on condition [0x002af000..0x002afe54]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283)
> 	at HostNode.main(HostNode.java:607)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:19:49 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:19:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-272) allow xpath
 expression/query to create more than one occurrence of an element
In-Reply-To: <21460509.1185436907082.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18633525.1186607989574.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-272?page=comments#action_12371548 ] 
            
Alejandro Guizar commented on BPEL-272:
---------------------------------------

Extra note: Oracle has deprecated the addChildNode() function and is also going for the extension operation approach:

http://forums.oracle.com/forums/thread.jspa?threadID=305968

"
Please don't use the addChildNode() function, this function is going to deprecated, instead use the new bpel extension insert/append (bpelx:append):
Syntax:
<bpel:assign>
<bpelx:append>
<bpelx:from ... />
<bpelx:to ... />
</bpelx:append>
</bpel:assign>
"

> allow xpath expression/query to create more than one occurrence of an element
> -----------------------------------------------------------------------------
>
>                 Key: BPEL-272
>                 URL: http://jira.jboss.com/jira/browse/BPEL-272
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The current XPath sublanguage implementation automatically creates nodes missing from location paths during assignment. This facility has a number of conceptual limitations. One of them is the inability to append a child element to an existing element if the latter already has a child element with the same name. There is no XPath syntax to express that a new element is required!
> It is tempting to think of a numeric XPath predicate as an array index, leading to the next snippet:
> <copy>
>  <from><literal>haha</literal></from>
>  <to variable='laughter' xmlns:ex='http://jbpm.org/bpel/examples'>
>   <query>ex:laugh[last() + 1]</query>
>  </to>
> </copy>
> However, such an interpretation of a predicate is wrong. Consider the following extract from XPath 1.0 specification on predicates:
> "A PredicateExpr is evaluated by evaluating the Expr and converting the result to a boolean. If the result is a number, the result will be converted to true if the number is equal to the context position and will be converted to false otherwise."
> The description of the last() function reads:
> "The last function returns a number equal to the context size from the expression evaluation context."
> Noticed the problem? The context position is never greater than the context size. Therefore the predicate [last() + 1] does not represent the position "one past the context size" but the boolean value false. Unfortunately, no other predicate seems appropriate. 
> PROPOSAL Introduce a minor deviation from the XPath 1.0 specification. Interpret the result of a numeric predicate that equals the context size plus one as a  request to create a new occurrence of the 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 lists.jboss.org  Wed Aug  8 17:48:02 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 17:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
In-Reply-To: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30839466.1186609682276.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4597?page=all ]

Alexey Loubyansky resolved JBAS-4597.
-------------------------------------

    Resolution: Done

Fixed.

> CacheInvalidator.areInvalid doesn't lock partitions
> ---------------------------------------------------
>
>                 Key: JBAS-4597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1, JBossAS-4.0.5.SP1 
>
>
> org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 17:48:02 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Aug 2007 17:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4597)
 CacheInvalidator.areInvalid doesn't lock partitions
In-Reply-To: <4823582.1186580809668.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3443111.1186609682448.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4597?page=all ]

Alexey Loubyansky closed JBAS-4597.
-----------------------------------


> CacheInvalidator.areInvalid doesn't lock partitions
> ---------------------------------------------------
>
>                 Key: JBAS-4597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4597
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.4.0.CR1, JBossAS-4.0.5.SP1 
>
>
> org.jboss.ejb.plugins.cmp.jdbc2.schema.CacheInvalidator.areInvalid(Serializable[] keys) uses cache.lock() before removing an instance. The lock() implementation in PartitionedTableCache is empty. It should either lock all the partitions or CacheInvalidator should lock the partition the key belongs to before the key 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 lists.jboss.org  Wed Aug  8 17:49:49 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-260) Flow activity might
 not reactivate parent token in race condition
In-Reply-To: <8655137.1183310457582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30673641.1186609789303.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-260?page=all ]

Alejandro Guizar resolved BPEL-260.
-----------------------------------

    Resolution: Done

> Flow activity might not reactivate parent token in race condition
> -----------------------------------------------------------------
>
>                 Key: BPEL-260
>                 URL: http://jira.jboss.com/jira/browse/BPEL-260
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> The flow activity suffers from the same problem as the join node in jPDL. When child tokens complete the nested activities concurrently, it is possible that all of them determine that the parent token must not be reactivated yet, leading to deadlock. The cause of this behavior is transaction isolation.
> To prevent this problem, the code to leave the flow must acquire exclusive access to the state of the concurrent tokens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:18 2007
From: jira-events at lists.jboss.org (Jerry Gauthier (JIRA))
Date: Wed, 8 Aug 2007 17:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3532) Inject DRM and DS
 into ClusterPartition
In-Reply-To: <5088873.1155941679968.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19444178.1186609938304.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3532?page=comments#action_12371552 ] 
            
Jerry Gauthier commented on JBAS-3532:
--------------------------------------

Modified implementation so that DRM is now injected into ClusterPartition and vice-versa.  This is different than the DistributedState implementation where DistributedState is injected into ClusterPartitionConfig which is then passed into ClusterPartition in its constructor.

I was initially unable to resolve circular dependencies between ClusterPartition and DRM when I tried injecting DRM into ClusterPartitionConfig so the newimplementation injects DRM into ClusterPartition itself.  I've left this issue open as I intend to revisit the use of DRM with ClusterPartitionConfig.

> Inject DRM and DS into ClusterPartition
> ---------------------------------------
>
>                 Key: JBAS-3532
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3532
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Jerry Gauthier
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> DRM and DS are now independent services.  Inject them into ClusterPartiton so they can be exposed via HAPartition.
> ClusterPartition in create or start must confirm that the injected DRM and DS are using the same JChannelFactory and stack that it is.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-151) export the reference
 of the published endpoint
Message-ID: <25007765.1186609939421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-151?page=all ]

Alejandro Guizar resolved BPEL-151.
-----------------------------------

    Resolution: Done

> 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
>             Fix For: jBPM BPEL 1.1 GA
>
>
> 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 lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-261) use varbinary
 instead of varchar as data type to store dom elements
In-Reply-To: <19942189.1183411377618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14279188.1186609939574.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-261?page=all ]

Alejandro Guizar resolved BPEL-261.
-----------------------------------

    Resolution: Done

> use varbinary instead of varchar as data type to store dom elements
> -------------------------------------------------------------------
>
>                 Key: BPEL-261
>                 URL: http://jira.jboss.com/jira/browse/BPEL-261
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> The documentation for javax.xml.transform.stream.StreamResult {http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/stream/StreamResult.html} reads:
> Normally, a stream should be used rather than a [writer], so that the transformer may use instructions contained in the transformation instructions to control the encoding.
> It turns out byte streams are preferred over character streams. In consequence, the data type used to store dom elements in the database should be varbinary rather than varchar. Plus, the byte stream output lends itself better to compression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-262) redeliver messages
 whose handling fails due to stale state exceptions
In-Reply-To: <24810637.1183417437672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <184088.1186609939767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-262?page=all ]

Alejandro Guizar resolved BPEL-262.
-----------------------------------

    Resolution: Done

> redeliver messages whose handling fails due to stale state exceptions
> ---------------------------------------------------------------------
>
>                 Key: BPEL-262
>                 URL: http://jira.jboss.com/jira/browse/BPEL-262
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM. Upon message reception, a new transaction begins and process execution proceeds. It is possible that other portions of the process execute in separate transactions. Concurrent process execution may cause stale state or lock acquisition exceptions to be thrown in one or more transactions.
> PROPOSAL. Detect stale state and lock acquisition exceptions in JMS message listeners. Do not acknowledge the affected message. Recover the JMS 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 lists.jboss.org  Wed Aug  8 17:52:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-263) incorporate
 enterprise support features from jpdl
In-Reply-To: <22029896.1183627611000.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11001705.1186609939902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-263?page=all ]

Alejandro Guizar resolved BPEL-263.
-----------------------------------

    Resolution: Done

> incorporate enterprise support features from jpdl
> -------------------------------------------------
>
>                 Key: BPEL-263
>                 URL: http://jira.jboss.com/jira/browse/BPEL-263
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> jBPM jPDL 3.2 introduced a number of enterprise features, including a scheduler service based on the EJB timer service and a persistence service configured for JTA.   Due to its reliance on J2EE Web Services, jBPM BPEL always runs in an enterprise environment. Incorporating the enterprise features available in jPDL is a clear step towards taking better advantage of the functionality offered by the application 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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-264) NPE when dead-path
 elimination reaches a flow with local links
In-Reply-To: <4995666.1184838827080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26508613.1186609940042.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-264?page=all ]

Alejandro Guizar resolved BPEL-264.
-----------------------------------

    Resolution: Done

> NPE when dead-path elimination reaches a flow with local links
> --------------------------------------------------------------
>
>                 Key: BPEL-264
>                 URL: http://jira.jboss.com/jira/browse/BPEL-264
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-265) structured
 activities tell they
 are initial even if they are the targets of links
In-Reply-To: <27245367.1184840027145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12884001.1186609940202.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-265?page=all ]

Alejandro Guizar resolved BPEL-265.
-----------------------------------

    Resolution: Done

> structured activities tell they are initial even if they are the targets of links
> ---------------------------------------------------------------------------------
>
>                 Key: BPEL-265
>                 URL: http://jira.jboss.com/jira/browse/BPEL-265
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-266) incorporate
 targetNamespace in process definition versioning
In-Reply-To: <9147436.1184968007265.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11407405.1186609940344.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-266?page=all ]

Alejandro Guizar resolved BPEL-266.
-----------------------------------

    Resolution: Done

> incorporate targetNamespace in process definition versioning
> ------------------------------------------------------------
>
>                 Key: BPEL-266
>                 URL: http://jira.jboss.com/jira/browse/BPEL-266
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM So far, process definition versioning has ignored the targetNamespace attribute. Unlike jPDL, BPEL uses qualified names for processes. The targetNamespace attribute is mandatory and must be taken into account when determining the latest process definition for a given name.
> SOLUTION Extend the existing GraphSession with process deployment/query methods that explicitly take the targetNamespace as a parameter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-267) NPE extracting
 content from soap envelope containing default namespace declarations
In-Reply-To: <2721852.1184969687093.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2823228.1186609940484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-267?page=all ]

Alejandro Guizar resolved BPEL-267.
-----------------------------------

    Resolution: Done

> NPE extracting content from soap envelope containing default namespace declarations
> -----------------------------------------------------------------------------------
>
>                 Key: BPEL-267
>                 URL: http://jira.jboss.com/jira/browse/BPEL-267
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-269) enhance assignment
 logging capabilities
In-Reply-To: <33342002.1185080388867.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13958071.1186609940624.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-269?page=all ]

Alejandro Guizar resolved BPEL-269.
-----------------------------------

    Resolution: Done

> enhance assignment logging capabilities
> ---------------------------------------
>
>                 Key: BPEL-269
>                 URL: http://jira.jboss.com/jira/browse/BPEL-269
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM When a bpel:uninitializedVariable fault is thrown, it does not log which variable was uninitialized. Further, logging of extraction and assignment of values is generally scarce. 
> SOLUTION Log the uninitialized variables. Add extraction/assignment logs to all from/to variants.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-270) Add support for
 extensionAssignOperation
In-Reply-To: <13309174.1185081467208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22902965.1186609940772.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-270?page=all ]

Alejandro Guizar resolved BPEL-270.
-----------------------------------

    Resolution: Done

> Add support for extensionAssignOperation
> ----------------------------------------
>
>                 Key: BPEL-270
>                 URL: http://jira.jboss.com/jira/browse/BPEL-270
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM In BPEL 2, <extensibleAssignOperation> elements can appear as children of the <assign> activity, alongside standard <copy> elements. Our current design does not permit the addition of custom assign operations.
> SOLUTION Generalize Copy to AssignOperation. Introduce a parsing framework that permits the creation of custom 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 lists.jboss.org  Wed Aug  8 17:52:20 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-271) NPE when a start IMA
 references a nonglobal variable
In-Reply-To: <20192567.1185408767068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <163282.1186609940938.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-271?page=all ]

Alejandro Guizar resolved BPEL-271.
-----------------------------------

    Resolution: Done

> NPE when a start IMA references a nonglobal variable
> ----------------------------------------------------
>
>                 Key: BPEL-271
>                 URL: http://jira.jboss.com/jira/browse/BPEL-271
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1 GA
>
>
> A start IMA (inbound message activity) can legally occur inside a scope and variables local to that scope. The revised ATM example illustrates this scenario. When jBPM BPEL delivers a message to the aforementioned IMA, it causes a NPE because it initializes global variables only.
> This problem affects references to non-global partner links and correlation sets 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 lists.jboss.org  Wed Aug  8 17:52:21 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-273) provide a
 declarative way to
 install new evaluator factories in the sublanguage framework
In-Reply-To: <14864822.1185917029305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29437658.1186609941098.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-273?page=all ]

Alejandro Guizar resolved BPEL-273.
-----------------------------------

    Resolution: Done

> provide a declarative way to install new evaluator factories in the sublanguage framework
> -----------------------------------------------------------------------------------------
>
>                 Key: BPEL-273
>                 URL: http://jira.jboss.com/jira/browse/BPEL-273
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The sublanguage framework is extensible; however, it only provides programmatic means to register evaluator factories for new languages.
> PROPOSAL Involves two actions:
> 1. Apply the resource-based declarative pattern currently employed in activity readers, catalog readers and endpoint reference factories to evaluator factories. 
> 2. Remove programmatic registration as well. It would allow the addition of new languages at runtime, which is untested and not currently 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 lists.jboss.org  Wed Aug  8 17:52:21 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-274) wsdl service
 generator: eliminate reliance on transitive imports
In-Reply-To: <19592587.1186087614143.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1165144.1186609941245.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-274?page=all ]

Alejandro Guizar resolved BPEL-274.
-----------------------------------

    Resolution: Done

> wsdl service generator: eliminate reliance on transitive imports
> ----------------------------------------------------------------
>
>                 Key: BPEL-274
>                 URL: http://jira.jboss.com/jira/browse/BPEL-274
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM Consider the following network of WSDL documents.
> <definitions name="d1" targetNamespace="ns1">
>  <import namespace="ns2" location="d2" />
>  <binding name="b" type="ns3:pt" />
> </definitions>
> <definitions name="d2" targetNamespace="ns2">
>  <import namespace="ns3" location="d3" />
>  <partnerLinkType name="plt">
>   <role portType="ns3:pt" />
>  </partnerLinkType>
> </definitions>
> <definitions name="d3" targetNamespace="ns3">
>  <portType name="pt" />
> </definitions>
> ns2:plt is able to resolve the reference tons3:pt, but ns1:b is not. The import element in d1 is not scanned because the binding refers to a port type in namespace ns3 and the import namespace URI is ns2. 
> jBPM BPEL is able to resolve such transitive references, but products like the Eclipse BPEL designer and JBossWS are not. 
> PROPOSAL While generating d1, create a direct import for d3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 17:52:21 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Wed, 8 Aug 2007 17:52:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-175) reintroduce
 assignment to/from variable/part/query
Message-ID: <28744498.1186609941398.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-175?page=all ]

Alejandro Guizar resolved BPEL-175.
-----------------------------------

    Fix Version/s: jBPM BPEL 1.1 GA
                       (was: jBPM BPEL 1.1 beta 1)
       Resolution: Done

AssignReader now parses the BPEL 2 syntax.

> reintroduce assignment to/from variable/part/query
> --------------------------------------------------
>
>                 Key: BPEL-175
>                 URL: http://jira.jboss.com/jira/browse/BPEL-175
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>         Environment: dom, trax
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> Item 103 of the BPEL issues list (http://www.choreology.com/external/WS_BPEL_issues_list.html) proposed a new syntax to access process variables within XPath expressions. The original proposal eliminated the variable/part/query variant of from-spec and to-spec, so it was removed from the product.
> After quite some discussion this variant remained valid. Therefore, the variant must be reintroduced. In fact this is a positive thing because it simplifies upgrading documents written against version 1.1 to version 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 lists.jboss.org  Wed Aug  8 18:07:52 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Wed, 8 Aug 2007 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13798863.1186610872068.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12371556 ] 
            
Imran Naqvi commented on GPD-78:
--------------------------------

I just tested with the new code and I'm afraid the problem still exists. GenericElements (formerly ConfigInfoElements) are not added to an Action. The fix for this is commented out in ActionDomAdapter.initialize()
The following lines of code in that method are commented out:
//			GenericElement[] genericElements = action.getGenericElements();
//			for (int i = 0; i < genericElements.length; i++) {
//				addElement(genericElements[i]);
//			}

If we uncomment this it should work. We need similar code in GenericElementXmlAdapter.initialize()
A sample process definition to reproduce this problem is:
<?xml version="1.0"?> 

<process-definition name="Movie" version="11"> 
<start-state name="Start"> 
<transition to="Get MPEG Properties" /> 
</start-state> 
<node name="Get MPEG Properties"> 
<action class="SomeActionHandler"><send>010901</send> 
<keys> 
<entry> 
                                            <key>VarName</key> 
                                            <value>1122</value> 
                                </entry> 
</keys> 
<receive> 
<element>030101</element> 
<element>030102</element> 
</receive> 
</action> 
<transition to="End"/> </node> 
<end-state name="End" /> 

The GenericElements in the Action in the above process definition never get added.

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  8 18:09:53 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Wed, 8 Aug 2007 18:09:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7536614.1186610993883.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12371557 ] 
            
Imran Naqvi commented on GPD-78:
--------------------------------

btw tried reopening the issue myself but I dont think I have permissions for it.

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.CR
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Wed Aug  8 18:32:49 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 8 Aug 2007 18:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7463384.1186612369477.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371558 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

the only new artifact in the pom is jboss-common. concurrent was added atm, but it will be removed with a newer version of jboss-aop. i believe that including jboss-common will not "tie you in" in any way, but its needed to use aopc. i dont have very strong feelings about this, but atm i feel that this would make it easier for the end user. please prove me wrong :)

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug  8 19:06:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Aug 2007 19:06:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-992) Give wiki pages
	a facelift
In-Reply-To: <4544515.1181946808835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30696988.1186614409988.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-992?page=all ]

Tim Fox closed JBMESSAGING-992.
-------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)
       Resolution: Done

> Give wiki pages a facelift
> --------------------------
>
>                 Key: JBMESSAGING-992
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-992
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: Unscheduled
>
>
> The current wiki pages - both user and development contain outdated information.
> We should update info, and add new content as 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 lists.jboss.org  Wed Aug  8 20:17:49 2007
From: jira-events at lists.jboss.org (Jeff Wang (JIRA))
Date: Wed, 8 Aug 2007 20:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-139) Cannot add tasks to
	the task node
Message-ID: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot add tasks to the task node
---------------------------------

                 Key: GPD-139
                 URL: http://jira.jboss.com/jira/browse/GPD-139
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
            Reporter: Jeff Wang
         Assigned To: Koen Aers


I am unable to add new tasks in the task node. When I go to the
tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:48:03 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1059) Online typos in
	Section 1
In-Reply-To: <15111425.1186340029389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9782517.1186620483846.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1059?page=all ]

Mark Proctor updated JBRULES-1059:
----------------------------------

    Fix Version/s: 4.0.1

> Online typos in Section 1
> -------------------------
>
>                 Key: JBRULES-1059
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1059
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: n/a  - concerns documentation availble for viewing over internet
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> miscellaneous typos
> http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/index.html
> Section 1.1
> modiied ? modified
> Drools will adding ? Drools will be adding
> Section 1.2.1
> explination ? explanation
> layed ? laid
> espically ? especially
> knowlegde ? knowledge
> Section 1.2.4
> preceeding ? preceding
> its ? it's
> Section 1.3.1
> shortley ? shortly
> Section 1.3.2
> conjuntive ? conjunctive
> disjuntive ? disjunctive
> Section 1.6.1
> grammer ? grammar
> deployeable ? deployable
> PackagBuilder ? PackageBuilder
> Section 1.6.4.6
> In the shaded box, should 'new List' simply be 'List' ?
> Section 1.6.5
> legible ? eligible
> section 1.6.6.1
> managable ? manageable
> section 1.6.7
> AgendEventListener ? AgendaEventListener

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:49:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4429942.1186620589853.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1027?page=all ]

Mark Proctor updated JBRULES-1027:
----------------------------------

    Fix Version/s: 4.0.1

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:49:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:49:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12277935.1186620590301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=all ]

Mark Proctor updated JBRULES-1056:
----------------------------------

    Fix Version/s: 4.0.1

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Wed Aug  8 20:49:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:49:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
In-Reply-To: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27136666.1186620590553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1058?page=all ]

Mark Proctor updated JBRULES-1058:
----------------------------------

    Fix Version/s: 4.0.1

> nested accessors with Sets - "not contains" is not a valid operator for MVEL
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-1058
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark McNally
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Following does not work:
> 		rule StateMatch
> 			when
> 			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
> 			then 	
> 				retract( $ca );
> 		end
> 		
> 		
> 		public class CandidateAssociation {
> 			private PatientDetails patientDetails;
> 			private NurseDetails   nurseDetails;
> 			private int overlapHours;
> 		
> 			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
> 				super();
> 				this.patientDetails = patientDetails;
> 				this.nurseDetails = nurseDetails;
> 				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
> 			}
> 		    [...]
> 		}
> 		
> 		public class NurseDetails {
> 			private Set stateLicensures = new HashSet();
> 			[...]
> 		}
> 		public class PatientDetails {
> 			private String state;
> 			[...]
> 		}
> Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 
> Also Noticed that the following workaround did not work:
> 		rule State
> 		    dialect "mvel"
> 			when
> 		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
> 			then 	
> 		  	    retract( $ca );
> 		end
> 		
> 		This produced this Exception:
> 		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
> 	        at org.drools.rule.Package.checkValidity(Package.java:408)
> 	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	        at [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:59:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1067) Allow RuleAgent
 to take a RuleBaseConfiguration to configure the RuleBase it creates
In-Reply-To: <28877644.1186573549478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13369884.1186621189582.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1067?page=all ]

Mark Proctor updated JBRULES-1067:
----------------------------------

    Fix Version/s: 4.0.1

> Allow RuleAgent to take a RuleBaseConfiguration to configure the RuleBase it creates
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1067
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1067
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Extend the API to allow a RuleAgent to use a  RuleBaseConfiguration object to configure the RuleBase it creates. For example, this will allow a user to specfiy options like Sequental mode etc when creating a RuleBase using a RuleAgent.
> I know that you can set RuleBase options for all RuleBases by setting the appropriate System properties when calling the java VM, but it would be nice to be able to set these individually via the API for each RuleBase created using a RuleAgent. I guess this could be done fairly easily by adding an extra constructor(s) to RuleAgent that takes a RuleBaseConfiguration object -- rbConfig, say -- and in RuleAgent when it creates a new RuleBase instead of just using RulebaseFactory.newRuleBase() use RulebaseFactory.newRuleBase(rbConfig) 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 lists.jboss.org  Wed Aug  8 20:59:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:59:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1061) jsr94 constants
 wrong package
 builder config constant, same name as rulebase config constant
In-Reply-To: <28549329.1186406629349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13161338.1186621189971.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1061?page=all ]

Mark Proctor updated JBRULES-1061:
----------------------------------

    Fix Version/s: 4.0.1

> jsr94 constants wrong package builder config constant, same name as rulebase config constant
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1061
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1061
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSR94
>    Affects Versions:  4.0.0.GA
>            Reporter: Juergen none
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> org.drools.jsr94.rules.Constants, line 49f:
>     /** <code>RuleExecutionSet</code> rulebase config constant. */
>     public static final String RES_RULEBASE_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";
>     
>     /** <code>RuleExecutionSet</code> package builder config constant. */
>     public static final String RES_PACKAGEBUILDER_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";    
> Packagebuilder config constant is same as rulebase config constant. yields classcast exception if a rulebase config is set:
> Caused by: java.lang.ClassCastException: org.drools.RuleBaseConfiguration
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:124)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 20:59:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 20:59:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1064) "->" notation
 for predicates missing in documentation
In-Reply-To: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21771001.1186621190250.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1064?page=comments#action_12371561 ] 
            
Mark Proctor commented on JBRULES-1064:
---------------------------------------

Any feedback or documentation changes recommendations for this?

> "->" notation for predicates missing in documentation
> -----------------------------------------------------
>
>                 Key: JBRULES-1064
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>            Priority: Minor
>
> the notation "->" for adressing complex terms is missing from 4.0.0 documentation.
> It has been "return value operator" in 3.0.6:
> <quoted from 3.0.6>
> Example 3.13. Return Value operator
> Person( girlAge : age, sex = "F" )
> Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
> </quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 21:54:05 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 21:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1067) Allow RuleAgent to
 take a RuleBaseConfiguration to configure the RuleBase it creates
In-Reply-To: <28877644.1186573549478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12058289.1186624445156.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1067?page=all ]

Mark Proctor closed JBRULES-1067.
---------------------------------

    Resolution: Done

> Allow RuleAgent to take a RuleBaseConfiguration to configure the RuleBase it creates
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1067
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1067
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Extend the API to allow a RuleAgent to use a  RuleBaseConfiguration object to configure the RuleBase it creates. For example, this will allow a user to specfiy options like Sequental mode etc when creating a RuleBase using a RuleAgent.
> I know that you can set RuleBase options for all RuleBases by setting the appropriate System properties when calling the java VM, but it would be nice to be able to set these individually via the API for each RuleBase created using a RuleAgent. I guess this could be done fairly easily by adding an extra constructor(s) to RuleAgent that takes a RuleBaseConfiguration object -- rbConfig, say -- and in RuleAgent when it creates a new RuleBase instead of just using RulebaseFactory.newRuleBase() use RulebaseFactory.newRuleBase(rbConfig) 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 lists.jboss.org  Wed Aug  8 23:03:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:03:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1061) jsr94 constants
 wrong package
 builder config constant, same name as rulebase config constant
In-Reply-To: <28549329.1186406629349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31514478.1186628629386.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1061?page=all ]

Mark Proctor closed JBRULES-1061.
---------------------------------

    Resolution: Done

> jsr94 constants wrong package builder config constant, same name as rulebase config constant
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1061
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1061
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSR94
>    Affects Versions:  4.0.0.GA
>            Reporter: Juergen none
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> org.drools.jsr94.rules.Constants, line 49f:
>     /** <code>RuleExecutionSet</code> rulebase config constant. */
>     public static final String RES_RULEBASE_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";
>     
>     /** <code>RuleExecutionSet</code> package builder config constant. */
>     public static final String RES_PACKAGEBUILDER_CONFIG = "javax.rules.admin.RuleExecutionSet.ruleBaseConfiguration";    
> Packagebuilder config constant is same as rulebase config constant. yields classcast exception if a rulebase config is set:
> Caused by: java.lang.ClassCastException: org.drools.RuleBaseConfiguration
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:124)
>         at org.drools.jsr94.rules.admin.LocalRuleExecutionSetProviderImpl.createRuleExecutionSet(LocalRuleExecutionSetProviderImpl.java:93)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:05:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4258490.1186628749342.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12371565 ] 
            
Mark Proctor commented on JBRULES-1065:
---------------------------------------

It should work we have the following unit test, which passes:
rule "test auto bindings 1"
when
	$p : Person();
	$c : Cheese( type == $p.likes, price == $c.price  )
then
    results.add( $p );
end

If you are sure this is a bug, you'll need to upload a self contained example that shows this regression.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Mark Proctor
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug  8 23:11:21 2007
From: jira-events at lists.jboss.org (Justin Zhou (JIRA))
Date: Wed, 8 Aug 2007 23:11:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-153) EJB timer
 clustering and failover support
In-Reply-To: <28686742.1163405681641.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31654626.1186629081798.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-153?page=comments#action_12371566 ] 
            
Justin Zhou commented on JBCLUSTER-153:
---------------------------------------

I am using jbpm ejb timer task executors. It will be nice the failover can work. 

> EJB timer clustering and failover support
> -----------------------------------------
>
>                 Key: JBCLUSTER-153
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-153
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>
> Support for clustered EJB timer service providing failover

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:17:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11846750.1186629469477.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1027?page=comments#action_12371567 ] 
            
Mark Proctor commented on JBRULES-1027:
---------------------------------------

I've tired this with the latest mvel and cannot reproduce the error.

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:33:00 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28335906.1186630380355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1027?page=all ]

Mark Proctor closed JBRULES-1027.
---------------------------------

    Resolution: Cannot Reproduce Bug

This does not fail with trunk, unit test was added anyway.

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:38:49 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 23:38:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
Message-ID: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE in BisocketClientInvoker$PingTimerTask
------------------------------------------

                 Key: JBREM-790
                 URL: http://jira.jboss.com/jira/browse/JBREM-790
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
            Priority: Minor
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Wed Aug  8 23:44:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 8 Aug 2007 23:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7392074.1186631041088.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-790?page=comments#action_12371569 ] 
            
Ron Sigal commented on JBREM-790:
---------------------------------

Fix applied to remoting_2_2_0_GA branch.

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Wed Aug  8 23:44:02 2007
From: jira-events at lists.jboss.org (Justin Zhou (JIRA))
Date: Wed, 8 Aug 2007 23:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-983) concurrent process
 execution fails
In-Reply-To: <30055235.1181555411656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11347051.1186631042180.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-983?page=comments#action_12371570 ] 
            
Justin Zhou commented on JBPM-983:
----------------------------------

I am using oracle 10g. If set treecache isolation to serializable, fork/join works for me, but not other levels. The problem is the treecache locking, looks like every transaction will lock the whole cache tree from root, under heavy load, lock timeout can happen. Is there anyway we can do lock a little smarter?

Will setting the datasource isolation level to serializable help? Unfortunately, I can not do it with oracle XA datasource.

So my question is that is this a bug or just a database isolation level issue?


> concurrent process execution fails
> ----------------------------------
>
>                 Key: JBPM-983
>                 URL: http://jira.jboss.com/jira/browse/JBPM-983
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: Hypersonic in-memory database, JobExecutor configured with 5 threads
>            Reporter: Alexander Schlett
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM 3.3
>
>         Attachments: SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java
>
>
> concurrent execution of async nodes with multiple JobExecutor threads fails. the effect is:
> 1) job sync within JobExecutor fails due to org.hibernate.StaleObjectStateException
> 2) process gets stuck in join node and never ends
> junit test for this is attached, it's a simple process with just a fork and a join and some scripts inbetween.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug  8 23:49:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:49:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10658573.1186631389420.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12371571 ] 
            
Mark Proctor commented on JBRULES-1060:
---------------------------------------

I just ran this and got:
[ObjectInserted: handle=[fid:1260:1260:a Garbage { someNumber= 310, id= C }]; object=a Garbage { someNumber= 310, id= C }]
java.lang.OutOfMemoryError


Which means its running out of memory, just give your JVM session access to more memory.

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Wed Aug  8 23:53:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 8 Aug 2007 23:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13289089.1186631629399.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12371572 ] 
            
Mark Proctor commented on JBRULES-1060:
---------------------------------------

notice you have a nested loop:
            for (int i = 1; i <= 3; i++) {
                for (int j = 1; j <= 475; j++) {
so thats actually 1425 facts its attempting to insert.

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Thu Aug  9 02:13:49 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 9 Aug 2007 02:13:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10842486.1186640029470.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371574 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

I have now done some changes in the POM 
1) I add trove to the client pom
2) I removed dependency of the plugin
THIS WORKS !!!!!!!!!! --> I do not get maven artifacts in the final product !!!!! GOOD!!!!

BUT still I'm a little worried. I cannot write <scope>provided</scope> to any of the artifacts below....
To my understanding of maven I should be able to do that....

In the compiler plugin it is possible to write provided.
I think we should see how that plugin works !!!!!!
Or we should ask for help at maven.org??
It is still the MOJO statement cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
that worries me.
I have tried to use project.getCompileClasspathElements() but with the very same result..... 


    <dependency>
      <groupId>trove</groupId>
      <artifactId>trove</artifactId>
      <version>1.1-beta-5</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-aop</artifactId>
      <version>2.0.0.alpha2</version>
    </dependency>
    <dependency>
      <groupId>jboss</groupId>
      <artifactId>jboss-common</artifactId>
      <version>4.0.2</version>
    </dependency>
    <dependency>
      <groupId>concurrent</groupId>
      <artifactId>concurrent</artifactId>
      <version>1.3.4</version>
    </dependency>


About strong fealings !!!!!!
====================
1) Yes I have strong fealings, I do belive that the plugin should not add any artifact to the end product (or client-artifact) "behind the schenes" --> such things will end up in errors.

2) A rule is that the plugin should NOT be in the client dependency list.
I have worked quite a lot with maven2 and I have never seen this before :-)


3) At the same time the compile time artifacts that AOPC uses, ant the client NOT uses, should not be in the client-artifact as well.....
Therefore we are not finished yet :-)




> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 02:40:05 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Aug 2007 02:40:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14777820.1186641605928.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

    Attachment: jboss-remoting.jar

Attached jboss-remoting.jar with fixes for all issues associated with Remoting 2.2.0.SP1 release.  It represents the state of the remoting_2_2_0_GA branch at tag remoting_2_2_1_SP1_Beta.

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.SP1
>
>         Attachments: jboss-remoting.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 lists.jboss.org  Thu Aug  9 02:55:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 02:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1127272.1186642549659.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers reopened GPD-78:
--------------------------

             

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Thu Aug  9 02:55:49 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 02:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18601869.1186642549840.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers updated GPD-78:
-------------------------

        Fix Version/s: jBPM JPDL Designer 3.1.0.GA
                           (was: jBPM JPDL Designer 3.1.0.CR)
    Affects Version/s: jBPM JPDL Designer 3.1.0.CR
                           (was: jBPM JPDL Designer 3.1.0.beta2)

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Thu Aug  9 03:48:49 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Thu, 9 Aug 2007 03:48:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4587) NoClassDefFoundError
 java.lang.System
In-Reply-To: <6030030.1185874069379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32478936.1186645729407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4587?page=all ]

Aleksandar Kostadinov updated JBAS-4587:
----------------------------------------

    Comment: was deleted

> NoClassDefFoundError java.lang.System
> -------------------------------------
>
>                 Key: JBAS-4587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4587
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions:  JBossAS-5.0.0.Beta3
>         Environment: QA Lab, VM, Sun JDK 1.5
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Scott M Stark
>         Attachments: server_log.zip, server_log_1.zip
>
>
> In the QA Lab we come across an issue when trying to run the JBoss AS test suite on VMs (see trace level log bolow). Consequences are that minimal server doesn't shutdown and test suite fails on starting the all configuration.
> To reproduce:
> Can be reproduced on a VM with sun jdk15 versions including 1.5.0_12. 
> Try ssh to qa01.qa.atl.jboss.com. On any issue ask in jboss-qa-internal at redhat.com or #jbossqa
> Checkout trunk.
> build/build.sh
> testsuite/build.sh jboss-minimal-tests
> The issue doesn't occur on physical machines as well jrockit is not affected.
> If that could be of any help I've found two issues with java.lang.System not found and gcj.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6371479
> http://www.linuxhelpforum.com/showthread.php?t=809687
> 2 server trace logs attached. Part of log see below:
> 2007-07-31 05:04:11,222 DEBUG [org.jboss.deployers.plugins.deployers.DeployersIm
> pl] Fully Undeployed vfsfile:/qa/services/hudson/hudson_workspace/workspace/JBos
> s_AS_Testsuite_HEAD-jdk15/src/build/output/jboss-5.0.0.Beta3/server/minimal/depl
> oy/shutdown.sar
> 2007-07-31 05:04:11,223 TRACE [org.jboss.system.server.profileservice.hotdeploy.
> HDScanner] End deployment scan
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=0
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System, loadClassDepth=1
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.UnifiedClassLoader] loadClas
> sImpl, name=java.lang.System, resolve=false
> 2007-07-31 05:04:11,223 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,224 TRACE [org.jboss.mx.loading.RepositoryClassLoader] loadC
> lass org.jboss.mx.loading.UnifiedClassLoader3 at fc9d2b{ url=null ,addedOrder=3} na
> me=java.lang.System not found
> 2007-07-31 05:04:11,225 ERROR [STDERR] Exception in thread "ExitOnShutdown"
> 2007-07-31 05:04:11,226 ERROR [STDERR] java.lang.NoClassDefFoundError: java/lang
> /System
> 2007-07-31 05:04:11,226 ERROR [STDERR]  at org.jboss.test.jmx.shutdown.ExitOnShu
> tdown$1.run(ExitOnShutdown.java:52)
> 2007-07-31 05:04:11,227 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 lists.jboss.org  Thu Aug  9 05:50:49 2007
From: jira-events at lists.jboss.org (Mariusz Olejnik (JIRA))
Date: Thu, 9 Aug 2007 05:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1037)
 JDBCPersistenceManager.java - reference should be inserted after message
 (ORA-02291: integrity constraint)
Message-ID: <21939514.1186653049587.JavaMail.jira@cloud.prod.atl2.jboss.com>

JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)
----------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1037
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037
             Project: JBoss Messaging
          Issue Type: Patch
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
         Environment: Windows XP / Oracle 10g
            Reporter: Mariusz Olejnik
         Assigned To: Tim Fox
            Priority: Critical
             Fix For: 1.4.0.CR1


Reference should be inserted after message because:
oracle-persistence-service.xml 
CREATE TABLE JBM_MSG_REF (
  CHANNEL_ID INTEGER, 
  MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) 
[...]



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 05:53:49 2007
From: jira-events at lists.jboss.org (Mariusz Olejnik (JIRA))
Date: Thu, 9 Aug 2007 05:53:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1037)
 JDBCPersistenceManager.java - reference should be inserted after message
 (ORA-02291: integrity constraint)
In-Reply-To: <21939514.1186653049587.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10510671.1186653229494.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1037?page=all ]

Mariusz Olejnik updated JBMESSAGING-1037:
-----------------------------------------

    Attachment: jboss-messaging-trunk-rev2988.patch

addReference(channelID, ref, psReference, false);
^
|
v
updateWithRetry(psMessage);

> JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1037
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>         Environment: Windows XP / Oracle 10g
>            Reporter: Mariusz Olejnik
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.4.0.CR1
>
>         Attachments: jboss-messaging-trunk-rev2988.patch
>
>
> Reference should be inserted after message because:
> oracle-persistence-service.xml 
> CREATE TABLE JBM_MSG_REF (
>   CHANNEL_ID INTEGER, 
>   MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) 
> [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 06:28:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 06:28:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1038) Client side
 failover hopping does not work
Message-ID: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>

Client side failover hopping does not work
------------------------------------------

                 Key: JBMESSAGING-1038
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.

if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".

Instead it should iterate through the list of delegates trying each one in turn.

Need to write a test for this 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 lists.jboss.org  Thu Aug  9 07:04:02 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1039) HTTP poller
	doesn't stop
Message-ID: <3265708.1186657442806.JavaMail.jira@cloud.prod.atl2.jboss.com>

HTTP poller doesn't stop
------------------------

                 Key: JBMESSAGING-1039
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1039
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


I have temporarily commented out clusterviewupdatetst::testUpdateMixedConnectionFactory since, once started, the HTTP poller doesn't stop.

Maybe this is a bug in remoting - need to investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 07:05:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 07:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1040) Update to
	Java 5 GUIDs
Message-ID: <11730897.1186657549288.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to Java 5 GUIDs
----------------------

                 Key: JBMESSAGING-1040
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1040
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 1


Since we are now Java 5 only, we can update to Java 5 guids.

We can also get rid of the message id generator 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 lists.jboss.org  Thu Aug  9 07:55:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 07:55:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26551267.1186660549359.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371598 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

I just downloaded a brand new Eclipse 3.3.0, Build : I20070625-1500, on my macbook pro, and installed JPDL Designer Plug-in 3.1.0 CR1, started a new jbpm project, created a new process definition, and straight away got the same error, so this is happening out of the box effectively on OSX.

Regards

Ross


> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 07:59:06 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 07:59:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1041) Bug in client
 side failover map updating
Message-ID: <24570873.1186660746148.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bug in client side failover map updating
----------------------------------------

                 Key: JBMESSAGING-1041
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1041
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


Consider this scenario:

There are three nodes in the cluster: 0, 1, 2.

Failover map is as follows:

0-->1
1-->2
2-->0

There is a connection on node 1.

Node 1 is killed.

Node 2 fails over for node 1.

An update is then sent to the client with the new failover map:

0-->2

2-->0

Client side failure is then detected

The client attempts failover, but there is no failover node specified in the map any more, since it has been updated.

Client fails to failover



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 07:59:06 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 07:59:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5070798.1186660746267.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371599 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

Can you attach the Eclipse log? Make sure you first remove everything that is not related to this issue.

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 08:00:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 08:00:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1041) Bug in
 client side failover map updating
In-Reply-To: <24570873.1186660746148.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31266400.1186660849781.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1041?page=comments#action_12371600 ] 
            
Tim Fox commented on JBMESSAGING-1041:
--------------------------------------

One solution to this, is not to overwrite the failovermap when the update occurs, but to *add* to the current map.

I.e the failover map on the client side after failover would read:

0-->2

1-->2

2-->0

So the client can still find the node after failure.

> Bug in client side failover map updating
> ----------------------------------------
>
>                 Key: JBMESSAGING-1041
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1041
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Consider this scenario:
> There are three nodes in the cluster: 0, 1, 2.
> Failover map is as follows:
> 0-->1
> 1-->2
> 2-->0
> There is a connection on node 1.
> Node 1 is killed.
> Node 2 fails over for node 1.
> An update is then sent to the client with the new failover map:
> 0-->2
> 2-->0
> Client side failure is then detected
> The client attempts failover, but there is no failover node specified in the map any more, since it has been updated.
> Client fails to failover

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 08:17:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 08:17:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16719767.1186661869457.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371605 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

in the log, each time I see this error I get the following:

Message : Problems occurred when invoking code from plug-in: "org.eclipse.jface", Plug-in: org.eclipse.jface, Date : 2007-........

I am not sure how to view a more detailed log,

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 08:34:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 08:34:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1041) Bug in client
 side failover map updating
In-Reply-To: <24570873.1186660746148.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15741301.1186662889302.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1041?page=all ]

Tim Fox closed JBMESSAGING-1041.
--------------------------------

    Resolution: Done

> Bug in client side failover map updating
> ----------------------------------------
>
>                 Key: JBMESSAGING-1041
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1041
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Consider this scenario:
> There are three nodes in the cluster: 0, 1, 2.
> Failover map is as follows:
> 0-->1
> 1-->2
> 2-->0
> There is a connection on node 1.
> Node 1 is killed.
> Node 2 fails over for node 1.
> An update is then sent to the client with the new failover map:
> 0-->2
> 2-->0
> Client side failure is then detected
> The client attempts failover, but there is no failover node specified in the map any more, since it has been updated.
> Client fails to failover

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 08:43:00 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Aug 2007 08:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-572) PIGGYBACK
Message-ID: <23476376.1186663380304.JavaMail.jira@cloud.prod.atl2.jboss.com>

PIGGYBACK
---------

                 Key: JGRP-572
                 URL: http://jira.jboss.com/jira/browse/JGRP-572
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.x


Oftentimes, JGroups sends messages which have only headers but no payload. These messages (e.g. heartbeats, stability/stable messages) could use another message to piggy back on. Or - if no regular message is sent within a certain timeout - all accumulated piggy back messages could be merged into one.
The advantage is that we send less traffic.
Implementation could be via a flag PIGGYBACK (same as OOB) in Message, and a protocol PIGGYBACK. The protocol accumulates all messages with the flag PIGGYBACK set, and attaches them to a regular message, or - when a timeout elapses - merges as many of the piggy back messages as possible and sends them as one message.

Note that this is not the same as the old PIGGYBACK protocol which used to be in JGroups a long time ago.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 09:16:55 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 09:16:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10835248.1186665415791.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371607 ] 
            
Paul Gier commented on JBAOP-453:
---------------------------------

If you want to add dependencies for the plugin to use that will not be included in the project artifact dependencies, you can add those dependencies to the plugin configuration.
For example:
  <plugin>
    <artifactId>maven-jbossaop-plugin</artifactId>
    <dependencies>
      <dependency>
        ...
      </dependency>
    </dependencies>
  </plugin>

Will that help your issue?

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 09:39:13 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Aug 2007 09:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14500762.1186666753531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371609 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

Doubleclick on the item in the Error Log View. A dialog will show up containing the stack trace.

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 09:40:50 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Thu, 9 Aug 2007 09:40:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6349767.1186666850014.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=all ]

Sohil Shah reopened JBPORTAL-1146:
----------------------------------

      Assignee: Sohil Shah  (was: Roy Russo)
             

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.6.Alpha1
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 09:50:49 2007
From: jira-events at lists.jboss.org (Tong Lee (JIRA))
Date: Thu, 9 Aug 2007 09:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5160227.1186667449403.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12371610 ] 
            
Tong Lee commented on JBRULES-1065:
-----------------------------------

Thanks for your reply and I agree your example works and it's not a bug.

Our issue is, we're trying to do  the following...

rule "auto binding ..."
when
  $c : Cheese ( price > weight )
then
  results.add( $c );
end

In above example, the PackageBuilder throws an Exception - Unable to return Declaration for identifier "weight".


> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Mark Proctor
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Thu Aug  9 09:50:49 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 09:50:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1042) Investigate
 possible casting issue with message bridge
Message-ID: <5137497.1186667449514.JavaMail.jira@cloud.prod.atl2.jboss.com>

Investigate possible casting issue with message bridge
------------------------------------------------------

                 Key: JBMESSAGING-1042
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1042
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 10:08:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 10:08:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19571762.1186668529354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-138?page=all ]

Ross McDonald reopened GPD-138:
-------------------------------

             
attaching stacktrace 

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 10:10:49 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Thu, 9 Aug 2007 10:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-138) error dialogue appears
 on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13945699.1186668649371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-138?page=all ]

Ross McDonald updated GPD-138:
------------------------------

    Attachment: stacktrace.txt

stacktrace attached

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Thu Aug  9 11:23:49 2007
From: jira-events at lists.jboss.org (Linoux Linoux (JIRA))
Date: Thu, 9 Aug 2007 11:23:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4598) TimerHandle failed
 to retrieve timer after JBoss restart
Message-ID: <103417.1186673029432.JavaMail.jira@cloud.prod.atl2.jboss.com>

TimerHandle failed to retrieve timer after JBoss restart
--------------------------------------------------------

                 Key: JBAS-4598
                 URL: http://jira.jboss.com/jira/browse/JBAS-4598
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.5.GA
         Environment: Windows XP / PostgreSQL
            Reporter: Linoux Linoux


Creating a timer, store the associated TimerHandle in DB.
Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.

----------------------------------------------------------
//In a Stateless Session :

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void createTimer() throws OgpException {
    TimerService ts = ctx.getTimerService();
    Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
    conf.setTestCleanTimerHandle(newTimer.getHandle());
    
    // Store conf in DB
}

private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
    if (conf.getTestCleanTimerHandle() == null)
      return null;
    try {
      return conf.getTestCleanTimerHandle().getTimer();
    } catch (NoSuchObjectLocalException e) {
        log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
       return null;
    }
}
----------------------------------------------------------

Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :

javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
        at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
        at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
        [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 11:32:49 2007
From: jira-events at lists.jboss.org (Linoux Linoux (JIRA))
Date: Thu, 9 Aug 2007 11:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4598) TimerHandle failed
 to retrieve timer after JBoss restart
In-Reply-To: <103417.1186673029432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9549690.1186673569351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4598?page=all ]

Linoux Linoux updated JBAS-4598:
--------------------------------

    Description: 
Creating a timer, store the associated TimerHandle in DB.
Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.

----------------------------------------------------------
//In a Stateless Session :

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void createTimer() throws OgpException {
    TimerService ts = ctx.getTimerService();
    Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
    conf.setTestCleanTimerHandle(newTimer.getHandle());
    
    // Store conf in DB
}

private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
    if (conf.getTestCleanTimerHandle() == null)
      return null;
    try {
      return conf.getTestCleanTimerHandle().getTimer();
    } catch (NoSuchObjectLocalException e) {
        log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
       return null;
    }
}
----------------------------------------------------------

Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :

javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
        at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
        at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
        [...]

JBoss uses the PostgreSQL database to store the timers and all other stuff. I have noted that the timers.timerid field changed after restarting JBoss, that could explain why the Timer is not found by the TimerHandle...

  was:
Creating a timer, store the associated TimerHandle in DB.
Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.

----------------------------------------------------------
//In a Stateless Session :

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void createTimer() throws OgpException {
    TimerService ts = ctx.getTimerService();
    Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
    conf.setTestCleanTimerHandle(newTimer.getHandle());
    
    // Store conf in DB
}

private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
    if (conf.getTestCleanTimerHandle() == null)
      return null;
    try {
      return conf.getTestCleanTimerHandle().getTimer();
    } catch (NoSuchObjectLocalException e) {
        log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
       return null;
    }
}
----------------------------------------------------------

Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :

javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
        at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
        at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
        [...]


> TimerHandle failed to retrieve timer after JBoss restart
> --------------------------------------------------------
>
>                 Key: JBAS-4598
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4598
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows XP / PostgreSQL
>            Reporter: Linoux Linoux
>
> Creating a timer, store the associated TimerHandle in DB.
> Restart JBoss server, try to get the Timer using the stored TimerHandle : javax.ejb.NoSuchObjectLocalException is thrown.
> ----------------------------------------------------------
> //In a Stateless Session :
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void createTimer() throws OgpException {
>     TimerService ts = ctx.getTimerService();
>     Timer newTimer = ts.createTimer(getTimerStartDate(), DateUtil.MILLIS_IN_DAY, testAge);
>     conf.setTestCleanTimerHandle(newTimer.getHandle());
>     
>     // Store conf in DB
> }
> private Timer getCurrentTimer(DbConfiguration conf) throws OgpException {
>     if (conf.getTestCleanTimerHandle() == null)
>       return null;
>     try {
>       return conf.getTestCleanTimerHandle().getTimer();
>     } catch (NoSuchObjectLocalException e) {
>         log.warn("Can't retrieve timer : it could be caused by the application redeployment", e);
>        return null;
>     }
> }
> ----------------------------------------------------------
> Using this code, call to getCurrentTimer after calling createTimer works fine, but after a JBoss restart, call to getCurrentTimer ends with a NoSuchObjectLocalException :
> javax.ejb.NoSuchObjectLocalException: Timer not available: [target=jboss.j2ee:service=EJB3,ear=ogp-app.ear,jar=ogp-ejb.jar,name=AdminCleanDbSessionBean]
>         at org.jboss.ejb.txtimer.TimerHandleImpl.getTimer(TimerHandleImpl.java:203)
>         at com.sts.ogp.ejb.admin.AdminCleanDbSessionBean.getCurrentTimer(AdminCleanDbSessionBean.java:157)
>         [...]
> JBoss uses the PostgreSQL database to store the timers and all other stuff. I have noted that the timers.timerid field changed after restarting JBoss, that could explain why the Timer is not found by the TimerHandle...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 11:41:49 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 9 Aug 2007 11:41:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29264517.1186674109427.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12371623 ] 
            
Mark Proctor commented on JBRULES-1065:
---------------------------------------

autovivification is only supported for return value and inline-evals. We further support nested property accessors, liek in the above example I pasted, and your first post. We don't support autovivification of any field. We won't fix this for the point release too, as its really a new feature request. I'll re-open this as a request for FUTURE.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Mark Proctor
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Thu Aug  9 11:43:49 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 9 Aug 2007 11:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1065) Unable to return
 Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25436721.1186674229649.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=all ]

Edson Tirelli reassigned JBRULES-1065:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Thu Aug  9 14:39:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 14:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1043) Make sure all
 examples work out of distro
Message-ID: <3531415.1186684741123.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make sure all examples work out of distro
-----------------------------------------

                 Key: JBMESSAGING-1043
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1043
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:39:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Aug 2007 14:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1044) Cleanup docs
 using xml editor
Message-ID: <5895634.1186684741257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cleanup docs using xml editor
-----------------------------

                 Key: JBMESSAGING-1044
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1044
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:45:01 2007
From: jira-events at lists.jboss.org (Dr. Gernot Starke (JIRA))
Date: Thu, 9 Aug 2007 14:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1068) Exception when
 adding
 "activation-group" attribute to otherwise correctly executed rule...
Message-ID: <25370522.1186685101163.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception when adding "activation-group" attribute to otherwise correctly executed rule...
------------------------------------------------------------------------------------------

                 Key: JBRULES-1068
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1068
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Eclipse 3.2
            Reporter: Dr. Gernot Starke
         Assigned To: Mark Proctor


rule "Golfer-Riddle with a single solution?" 
	activation-group="unique-solution"
    when
        // There is a golfer names Fred, 
        $f: Golfer( name == "Fred",
...

yields:
Exception in thread "main" org.drools.compiler.DroolsParserException: Unknown error while parsing. This is a bug. Please contact the Development team.
	at org.drools.compiler.DrlParser.compile(DrlParser.java:180)
	at org.drools.compiler.DrlParser.parse(DrlParser.java:61)
	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:19)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:47:01 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 9 Aug 2007 14:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1069) DSL sentence
 widget is too
 small and combobox with sentences should not be expanded
Message-ID: <21523644.1186685221254.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL sentence widget is too small and combobox with sentences should not be expanded
-----------------------------------------------------------------------------------

                 Key: JBRULES-1069
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1069
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Ahti Kitsik
         Assigned To: Ahti Kitsik
            Priority: Minor
             Fix For: 4.0.1


Reported by Kris Verlaenen:
There is still an issue with DSL in the guided editor:
if you add a DSL sentence, fill in some values, and then try to add
more sentences, the sentences shown in the drop-down box also contain
the filled in values ?

The size of the boxes in DSL sentences also seem to shrink to minimal
when adding new sentences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 14:47:01 2007
From: jira-events at lists.jboss.org (Dr. Gernot Starke (JIRA))
Date: Thu, 9 Aug 2007 14:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
Message-ID: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception with "not in" condition with  (int-values)
----------------------------------------------------

                 Key: JBRULES-1070
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions:  4.0.0.GA
         Environment: Eclipse 3.2
            Reporter: Dr. Gernot Starke
         Assigned To: Mark Proctor


// Bob wears plaid       
Golfer( name == "Bob", 
        $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
        $bobsColor : color == "plaid",
        color != $fredsColor, color != $joesColor,
        color != $fredsNeighbourColor )

yields the following exception
Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 15:21:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 15:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4599) JaasSecurityManager
	refactor
Message-ID: <19316533.1186687261058.JavaMail.jira@cloud.prod.atl2.jboss.com>

JaasSecurityManager refactor
----------------------------

                 Key: JBAS-4599
                 URL: http://jira.jboss.com/jira/browse/JBAS-4599
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For:  JBossAS-5.0.0.Beta3


JaasSecurityManager extends ServiceMBeanSupport. It needs to be refactor such that it reuses a bean from the security 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 lists.jboss.org  Thu Aug  9 15:31:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Aug 2007 15:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14838528.1186687861064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

    Attachment: jboss-remoting.jar

Attached new jboss-remoting.jar without extraneous log.info messages.

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.SP1
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Thu Aug  9 15:33:03 2007
From: jira-events at lists.jboss.org (Vladimir Schafer (JIRA))
Date: Thu, 9 Aug 2007 15:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1071)
 BinaryRuleBaseLoader doesn't accept custom ClassLoader
Message-ID: <2403729.1186687983991.JavaMail.jira@cloud.prod.atl2.jboss.com>

BinaryRuleBaseLoader doesn't accept custom ClassLoader
------------------------------------------------------

                 Key: JBRULES-1071
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1071
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Vladimir Schafer
         Assigned To: Mark Proctor
            Priority: Minor


AddPackage method of class BinaryRuleBaseLoader accepts custom classloader as a parameter, but this isn't propagated to DroolsObjectInputStream in addPackage method call. So custom class loading isn't available when constructing RuleBases from JBRMS packaged files.

Error is in file org.drools.util.BinaryRuleBaseLoader.java, Core module, line 81. Code ObjectInputStream oin = new DroolsObjectInputStream( in ); should be changed to ObjectInputStream oin = new DroolsObjectInputStream( in, classLoader ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 15:50:03 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 9 Aug 2007 15:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4600) Rename JBossMQ
 variables from
 jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into
 build-thirdparty
Message-ID: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty
---------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4600
                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: JBossAS-4.2.2.GA


It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 16:29:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 9 Aug 2007 16:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23049806.1186691341306.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371667 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Hi Again

I have now studiet the maven-compiler-plugin and discoverd how <scope>provided</scope> works.

The secret is to add compile to the  @requiresDependencyResolution annotation.


 * @requiresDependencyResolution compile

So with this fix I think JBAOP-453 can be solved

I have not tried Paul Giers suggestion.

One reason for this is that I do not know the reasoning for 4 dependencies.
For each artifact it is necessary to know which is AOPC compiler required and/or runtime required.????

If you fix the @requiresDependencyResolution  I think the problem is solved :-)

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 16:43:01 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Thu, 9 Aug 2007 16:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
Message-ID: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>

Installation / Build instructions do not match what SVN delivers
----------------------------------------------------------------

                 Key: JBRULES-1072
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.MR3
         Environment: WinXP on Dell desktop
            Reporter: Dave Dibble
         Assigned To: Mark Proctor


Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.

There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.

Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
C:\dev\jbossrules\drools-eclipse>ant clean-all
Buildfile: build.xml

BUILD FAILED
Target "clean-all" does not exist in the project "Build All Elements".

Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.

Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 16:46:19 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 9 Aug 2007 16:46:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28311835.1186692379568.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371669 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

I have now tried Paul Geirs solution

Below I have moved the 4 dependencies to the artifact.
error java.lang.NoClassDefFoundError: gnu/trove/TLongObjectHashMap tells me that the dependency list under the plugin does not appear on the CP by default.

But good news is that   Plugin plugin=(Plugin)project.getBuild().getPlugins().get(1);
plugin.getDependencies() --> list the four dependencyies !!!!!!!

So the problem is to add these also  --> very good solution.
I have a problem to find "current" plugin !!!! 
In my program it is nr 1 in the plugin list. I belive there is an instance current-plugin "sonewhere"

/Anders

  <build>
    <plugins>
      <plugin>
        <groupId>org.jboss.maven.plugins</groupId>
        <artifactId>maven-jbossaop-plugin</artifactId>
        <version>1.0-SNAPSHOT</version>
        <dependencies>
          <dependency>
            <groupId>trove</groupId>
            <artifactId>trove</artifactId>
            <version>1.1-beta-5</version>
          </dependency>
          <dependency>
            <groupId>jboss</groupId>
            <artifactId>jboss-aop</artifactId>
            <version>2.0.0.alpha2</version>
          </dependency>
          <dependency>
            <groupId>jboss</groupId>
            <artifactId>jboss-common</artifactId>
            <version>4.0.2</version>
          </dependency>
          <dependency>
            <groupId>concurrent</groupId>
            <artifactId>concurrent</artifactId>
            <version>1.3.4</version>
          </dependency>
        </dependencies>
        <executions>
          <execution>
            <phase>process-classes</phase>
            <configuration>
              <aoppath>${basedir}/../portal-wsrp-sar/src/main/resources/wsrp-aop.xml</aoppath>
              <verbose>true</verbose>
              <includes>
                <include>org/jboss/portal/wsrp/consumer/ConsumerRegistryService.class</include>
              </includes>
            </configuration>
            <goals>
              <goal>compile</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>


> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug  9 16:52:03 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Thu, 9 Aug 2007 16:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
In-Reply-To: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10892638.1186692723110.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1072?page=comments#action_12371671 ] 
            
Dave Dibble commented on JBRULES-1072:
--------------------------------------

It would appear that the documentation found at http://labs.jboss.com/auth/jbossrules/docs/index.html is different to what is retrieved from svn in a number of regards - the current svn documentation indicates a maven download is needed and different commands are used for the build. 

Would be nice to get a confirmation that the doc on the jboss website is out of date.

> Installation / Build instructions do not match what SVN delivers
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1072
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP on Dell desktop
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>
> Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.
> There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.
> Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
> C:\dev\jbossrules\drools-eclipse>ant clean-all
> Buildfile: build.xml
> BUILD FAILED
> Target "clean-all" does not exist in the project "Build All Elements".
> Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
> eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.
> Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 17:19:20 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Thu, 9 Aug 2007 17:19:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23596227.1186694360587.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

John Ruud updated GPD-78:
-------------------------


Koen,

Here's some of my node samples (as you can see they're similar to Imran's in complexity):

   <nodeSign name="nodeSign1">
      <action class="com.xyz.ActionSign">
         <MyTag>
            <SignatureType></SignatureType>
         </MyTag>
      </action>
   </nodeSign>

   <decideIsTime name="decision3">
      <handler class="com.xyz.DecideIsTime">
         <MyTag>
            <CompareDate>
               <DateTime format="HH:mm" operator="between"></DateTime>
            </CompareDate>
         </MyTag>
      </handler>
   </decideIsTime>

   <state name="state1">
      <event type="node-enter">
         <action class="com.xyz.SetTask">
            <MyTag>
               <ProcessingTypeID></ProcessingTypeID>
            </MyTag>
         </action>
      </event>
      <event type="node-leave">
         <action class="com.xyz.SetTaskClear"></action>
      </event>
   </state>

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Thu Aug  9 17:28:02 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Thu, 9 Aug 2007 17:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18013360.1186694882400.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371677 ] 
            
John Ruud commented on GPD-128:
-------------------------------

Koen,

The following method of mine no longer compiles, as XmlAdapterRegistry.getConfigurationElementByXmlElementName(String) no longer exists. Do you happen to know off the top of your head what the replacement would be (I haven't had the time to study your latest batch of changes yet, but I suspect there's probably better ways of doing this):

private static String getSemanticElementId(String elementName, SemanticElement parent) {
		XmlAdapterRegistry registry = RegistryRegistry.getXmlAdapterRegistry(parent.getFactory().getEditorId());
		IConfigurationElement configurationElement = 
			registry.getConfigurationElementByXmlElementName(elementName);
		if (configurationElement == null) 
			return null;
		return configurationElement.getAttribute("semanticElement");
	}

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Thu Aug  9 17:44:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-45) Assimilate the
 Higgins Project SPI
In-Reply-To: <17842793.1177708650271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6181578.1186695841134.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-45?page=all ]

Anil Saldhana updated SECURITY-45:
----------------------------------

    Fix Version/s: 2.0.2-GA
                       (was: 2.0.1.BETA)

> Assimilate the Higgins Project SPI
> ----------------------------------
>
>                 Key: SECURITY-45
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-45
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.2-GA
>
>
> There is a need to get the SPI for Project Higgins Trust Framework into the JBoss Security SPI.
> http://www.eclipse.org/higgins/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 17:44:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-30) Validate
 security_policy_5.0.xsd for JBAS
In-Reply-To: <30779788.1173285623901.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14446464.1186695841278.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-30?page=all ]

Anil Saldhana updated SECURITY-30:
----------------------------------

    Fix Version/s: 2.0.1
                       (was: 2.0.1.BETA)

> Validate security_policy_5.0.xsd for JBAS
> -----------------------------------------
>
>                 Key: SECURITY-30
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-30
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.0.BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1
>
>
> With the JSR-196 work taking the back-seat, there is a need to validate the security config xsd for JBoss5.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 17:46:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-41)
 JaasSecurityManagerService can
 show security provider/JCA algorithm information
In-Reply-To: <1401723.1175187486851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19940783.1186695961269.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-41?page=all ]

Anil Saldhana updated SECURITY-41:
----------------------------------

    Fix Version/s: 2.0.1
                       (was: 2.0.1.BETA)

> JaasSecurityManagerService can show security provider/JCA algorithm information
> -------------------------------------------------------------------------------
>
>                 Key: SECURITY-41
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-41
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.0.BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: 2.0.1
>
>
> JBAS-3400 has the 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 lists.jboss.org  Thu Aug  9 17:48:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 17:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-73) Release Security
	V2.0.1-BETA
In-Reply-To: <14609963.1186178033997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <647649.1186696081047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-73?page=all ]

Anil Saldhana closed SECURITY-73.
---------------------------------

    Resolution: Done

SPI archives are at:
http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/jboss/jboss-security-spi/2.0.1-BETA/

JBossSX archives are at:
http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/jboss/jbosssx/2.0.1-BETA/

Source Code tags:
http://anonsvn.jboss.org/repos/jbossas/projects/security/

> Release Security V2.0.1-BETA
> ----------------------------
>
>                 Key: SECURITY-73
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-73
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>    Affects Versions: 2.0.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1.BETA
>
>
> Release v2.0.1-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 lists.jboss.org  Thu Aug  9 18:09:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-375) Change surefire
 plugin to accept package names when running a single test.
In-Reply-To: <528775.1180706408529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28801201.1186697341100.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-375?page=all ]

Paul Gier closed JBBUILD-375.
-----------------------------

    Resolution: Done

Surefire plugin has been patched.

> Change surefire plugin to accept package names when running a single test.
> --------------------------------------------------------------------------
>
>                 Key: JBBUILD-375
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-375
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Currently the surefire plugin only accepts a slash delimited path when running a single test.
> mvn -Dtest=org/jboss/test/SomeTestCase test
> This should also accept a package path like this
> mvn -Dtest=org.jboss.test.SomeTestCase 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 lists.jboss.org  Thu Aug  9 18:14:15 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Aug 2007 18:14:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-72) i am getting the
 belwo error when i am trying to invalidate sessio object
In-Reply-To: <25399205.1185220907154.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18791498.1186697655278.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-72?page=all ]

Anil Saldhana closed SECURITY-72.
---------------------------------

    Resolution: Won't Fix

File in the AS forums.  If you do not need the SessionFlushListener, remove it from the web.xml in  the tomcat directory in deploy folder.

> i am getting the belwo error when i am trying to invalidate sessio object
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-72
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-72
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: v v
>         Assigned To: Anil Saldhana
>            Priority: Critical
>
> 2007-07-23 15:35:57,364 DEBUG [org.jboss.web.tomcat.security.SecurityFlushSessionListener] Obtaining SecurityManagerService failed::
> javax.naming.NameNotFoundException: securityMgr 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 org.jnp.server.NamingServer.lookup(NamingServer.java:270)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:270)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:716)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at org.jboss.web.tomcat.security.SecurityFlushSessionListener.getSecurityManagerService(SecurityFlushSessionListener.java:193)
> 	at org.jboss.web.tomcat.security.SecurityFlushSessionListener.getSubjectAndSecurityDomain(SecurityFlushSessionListener.java:160)
> 	at org.jboss.web.tomcat.security.SecurityFlushSessionListener.sessionDestroyed(SecurityFlushSessionListener.java:79)
> 	at org.apache.catalina.session.StandardSession.expire(StandardSession.java:687)
> 	at org.apache.catalina.session.StandardSession.expire(StandardSession.java:645)
> 	at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1090)
> 	at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:149)
> 	at com.standardandpoors.apps.defaultfilter.authentication.DefaultFilterLogoutHandler.execute(DefaultFilterLogoutHandler.java:55)
> 	at com.standardandpoors.framework.controller.BusinessLogicControllerBean.process(BusinessLogicControllerBean.java:170)
> 	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.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
> 	at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:64)
> 	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.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
> 	at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
> 	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.SessionContainer.internalInvoke(SessionContainer.java:648)
> 	at org.jboss.ejb.Container.invoke(Container.java:954)
> 	at sun.reflect.GeneratedMethodAccessor108.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.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
> 	at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
> 	at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:206)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:192)
> 	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 	at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 	at $Proxy205.process(Unknown Source)
> 	at com.standardandpoors.framework.controller.SpControllerServlet.doPost(SpControllerServlet.java:354)
> 	at com.standardandpoors.apps.defaultfilter.controller.DefaultFilterControllerServlet.doPost(DefaultFilterControllerServlet.java:81)
> 	at com.standardandpoors.framework.controller.SpControllerServlet.service(SpControllerServlet.java:255)
> 	at com.standardandpoors.apps.defaultfilter.controller.DefaultFilterControllerServlet.service(DefaultFilterControllerServlet.java:56)
> 	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 com.standardandpoors.apps.defaultfilter.security.JaasLoginFilter.doFilter(JaasLoginFilter.java:266)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at com.standardandpoors.apps.defaultfilter.controller.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:65)
> 	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.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
> 	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 lists.jboss.org  Thu Aug  9 18:22:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-382) Testrun of a
 project with
 circular dependencies errantly includes older version of itself
In-Reply-To: <20419530.1181768651657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3940866.1186698121157.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBBUILD-382?page=comments#action_12371685 ] 
            
Paul Gier commented on JBBUILD-382:
-----------------------------------

I wonder if the issue was related to this:
http://jira.codehaus.org/browse/SUREFIRE-61

Because looking at the test classpath, it looks like the local classes should have come first before the dependency.
The issue above caused the classpath ordering to be changed when the surefire plugin forked.

> Testrun of a project with circular dependencies errantly includes older version of itself
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-382
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-382
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: Maven
>            Reporter: Jason T. Greene
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> jboss-common-core has a dependency on jboss-test
>  <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-test</artifactId>
>       <version>1.0.3.GA</version>
>       <scope>test</scope>
>     </dependency>
> jboss-test has a dependancy on jboss-common-core
> <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common-core</artifactId>
>       <version>2.0.4.GA</version>
>     </dependency>
> This leads to the surefire classpath containing 2 versions of jboss-common-core in the classpath, and unfortunately the older version wins. This means the testsuite never actually runs on the version you are modifying, which is a severe problem. Maven should be smart enough not to include the same artifact-id twice.
> [DEBUG] Test Classpath :
> [DEBUG]   /devel/common-core/trunk/target/classes
> [DEBUG]   /devel/common-core/trunk/target/test-classes
> [DEBUG]   /home/jason/.m2/repository/apache-log4j/log4j/1.2.8/log4j-1.2.8.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-logging-spi/2.0.4.GA/jboss-common-logging-spi-2.0.4.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-log4j/2.0.2.GA/jboss-logging-log4j-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-core/2.0.2.GA/jboss-common-core-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/apache-slide/webdavlib/2.0/webdavlib-2.0.jar
> [DEBUG]   /home/jason/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> [DEBUG]   /home/jason/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/profiler/jvmti/jboss-profiler-jvmti/1.0.0.CR5/jboss-profiler-jvmti-1.0.0.CR5.jar
> [DEBUG]   /home/jason/.m2/repository/apache-xerces/xml-apis/2.7.1/xml-apis-2.7.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-spi/2.0.2.GA/jboss-logging-spi-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/apache-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.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 lists.jboss.org  Thu Aug  9 18:24:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-382) Testrun of a
 project with
 circular dependencies errantly includes older version of itself
In-Reply-To: <20419530.1181768651657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18012594.1186698241137.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-382?page=all ]

Paul Gier closed JBBUILD-382.
-----------------------------

    Resolution: Done

I don't think there is anything more to do on this issue.

> Testrun of a project with circular dependencies errantly includes older version of itself
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-382
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-382
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: Maven
>            Reporter: Jason T. Greene
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> jboss-common-core has a dependency on jboss-test
>  <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-test</artifactId>
>       <version>1.0.3.GA</version>
>       <scope>test</scope>
>     </dependency>
> jboss-test has a dependancy on jboss-common-core
> <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common-core</artifactId>
>       <version>2.0.4.GA</version>
>     </dependency>
> This leads to the surefire classpath containing 2 versions of jboss-common-core in the classpath, and unfortunately the older version wins. This means the testsuite never actually runs on the version you are modifying, which is a severe problem. Maven should be smart enough not to include the same artifact-id twice.
> [DEBUG] Test Classpath :
> [DEBUG]   /devel/common-core/trunk/target/classes
> [DEBUG]   /devel/common-core/trunk/target/test-classes
> [DEBUG]   /home/jason/.m2/repository/apache-log4j/log4j/1.2.8/log4j-1.2.8.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-test/1.0.3.GA/jboss-test-1.0.3.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-logging-spi/2.0.4.GA/jboss-common-logging-spi-2.0.4.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-log4j/2.0.2.GA/jboss-logging-log4j-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-common-core/2.0.2.GA/jboss-common-core-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/apache-slide/webdavlib/2.0/webdavlib-2.0.jar
> [DEBUG]   /home/jason/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> [DEBUG]   /home/jason/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/profiler/jvmti/jboss-profiler-jvmti/1.0.0.CR5/jboss-profiler-jvmti-1.0.0.CR5.jar
> [DEBUG]   /home/jason/.m2/repository/apache-xerces/xml-apis/2.7.1/xml-apis-2.7.1.jar
> [DEBUG]   /home/jason/.m2/repository/jboss/jboss-logging-spi/2.0.2.GA/jboss-logging-spi-2.0.2.GA.jar
> [DEBUG]   /home/jason/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> [DEBUG]   /home/jason/.m2/repository/apache-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.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 lists.jboss.org  Thu Aug  9 18:35:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 18:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-369) Work on a site
 plugin configuration that follows the jboss.org look and feel.
In-Reply-To: <2354415.1178727472297.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1101035.1186698901073.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-369?page=all ]

Paul Gier updated JBBUILD-369:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Work on a site plugin configuration that follows the jboss.org look and feel.
> -----------------------------------------------------------------------------
>
>                 Key: JBBUILD-369
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-369
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Create a maven skin with the look of the new jboss.org.
> Figure out how the maven generated sites should be deployed to jboss.org.
> Add reporting configuration to the jboss parent pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 19:12:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 19:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-369) Integration
 between maven generated sites and jboss.org
In-Reply-To: <2354415.1178727472297.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6886837.1186701121056.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-369?page=all ]

Paul Gier updated JBBUILD-369:
------------------------------

    Summary: Integration between maven generated sites and jboss.org  (was: Work on a site plugin configuration that follows the jboss.org look and feel.)

> Integration between maven generated sites and jboss.org
> -------------------------------------------------------
>
>                 Key: JBBUILD-369
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-369
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Create a maven skin with the look of the new jboss.org.
> Figure out how the maven generated sites should be deployed to jboss.org.
> Add reporting configuration to the jboss parent pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug  9 19:14:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 9 Aug 2007 19:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-391) Create jboss.org
 site for maven-jdocbook-plugin
In-Reply-To: <2058933.1183489497644.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16948477.1186701241071.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBBUILD-391?page=comments#action_12371692 ] 
            
Paul Gier commented on JBBUILD-391:
-----------------------------------

Some css issues still need to be resolved for the site to look good.

> Create jboss.org site for maven-jdocbook-plugin
> -----------------------------------------------
>
>                 Key: JBBUILD-391
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-391
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>
> Steve created the jdocbook plugin for maven.  This should be the new standard docbook configuration within jboss.  A site needs to be created for the plugin documentation on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 00:39:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 00:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7037607.1186720741603.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=all ]

Sohil Shah updated JBPORTAL-1146:
---------------------------------

    Fix Version/s: 2.4.2 Final
                   2.6.2 Final
                       (was: 2.6.Alpha1)

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 01:33:27 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 01:33:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <997021.1186724007844.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=all ]

Sohil Shah updated JBPORTAL-1146:
---------------------------------

    Fix Version/s: 2.8 Final

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.4.2 Final, 2.8 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 01:51:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 01:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14003670.1186725061373.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=all ]

Sohil Shah resolved JBPORTAL-1146.
----------------------------------

    Resolution: Done

The Zip File creation instead of using InputStream directly did the trick.

Also, some issues with properly creating path hierarchy needed fixing which was completely independent of the ZipFile issue 

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.4.2 Final, 2.6.2 Final, 2.8 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 02:00:11 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Fri, 10 Aug 2007 02:00:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14937462.1186725611806.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12371698 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

I have been thinking about Paul Geirs comment.
1) I have tried to add a dependency to the plugin that does not exist --> the build fails like a normal missing dependency --> GOOD. We can trust the dependency collection on the plugin.

2) If the user has added plugin-dependencies I simply think we should add it to the "-cp"
     Technically I think we can get the plugin-dependency-list by adding a menber-variable to the MOJO and 
     give it the correct annotation..
     I have not seen this membervariable yet.. But I will search a little for it.

3) If the user has NOT added plugin dependencies. I think we should add all the AOPC internal artifacts It needs to the "-cp"
     Technically this can be done by containing a list of these artifacts in the plugin / plugin's pom.xml and simply add these. I do not know how many it is??
3.a) Here we are back to my problem. I know nothing about AOPC .... You and others must help here ... and document what artifact is AOPC and what artifact is runtime relevant.

4) By this (2+3)  I belive we get the easy functionality you suggested.
5) By this we also keep the dependency system "clean". 
6) By this the user will have to add client-plugin-dependencies as normal if he/she wants it to become runtime dependencies.

7) This also asks for getting the documentation to the plugin done.
8) This also asks for a home-page for the site of the plugin.
9) On page http://labs.jboss.com/jbossaop/ I see a good place for a link to the site for this plugin :-)



> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Fri Aug 10 02:13:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 10 Aug 2007 02:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1609) cms cache
 dependency on cms service is flipped
In-Reply-To: <21687902.1185292727080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16093343.1186726381090.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1609?page=all ]

Sohil Shah resolved JBPORTAL-1609.
----------------------------------

    Resolution: Done

> cms cache dependency on cms service is flipped
> ----------------------------------------------
>
>                 Key: JBPORTAL-1609
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1609
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final, 2.4.1 Final, 2.4.1 SP1, 2.6 Final, 2.6.1 Final
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.4.2 Final, 2.4.3 Final, 2.6.2 Final, 2.8 Final
>
>
> The cms cache service currently depends on the portal cms service to start.
> The dependency should be such that portal cms service depends on cms cache service instead.
> Because of this bug, some cache configurations like cacheloader async=true settings seem to fail.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 02:22:39 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 10 Aug 2007 02:22:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-199) Add support
 for propagating TransientManagedObjects from structural deployers
In-Reply-To: <11389462.1185657407363.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17207129.1186726959313.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMICROCONT-199?page=comments#action_12371699 ] 
            
Scott M Stark commented on JBMICROCONT-199:
-------------------------------------------

Done except for the type safe Iterable implementation for multi-dimensional arrays.
See the FIXME in org.jboss.test.metatype.values.test.ArrayValueSupportUnitTestCase.test2DCharArray

> Add support for propagating TransientManagedObjects from structural deployers
> -----------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-199
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-199
>             Project: JBoss MicroContainer
>          Issue Type: Feature Request
>          Components: Deployment
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> We need the ability for a structure deployer to add attachments that can be used as input to regular deployers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 02:24:01 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 10 Aug 2007 02:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-202) Primative
 arrays are not
 handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
In-Reply-To: <17430949.1186533240797.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15419869.1186727041293.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMICROCONT-202?page=comments#action_12371700 ] 
            
Scott M Stark commented on JBMICROCONT-202:
-------------------------------------------

Done except for the type safe Iterable implementation for multi-dimensional arrays.
See the FIXME in org.jboss.test.metatype.values.test.ArrayValueSupportUnitTestCase.test2DCharArray

> Primative arrays are not handled correctly due to ArrayInfoImpl name & DefaultMetaValueFactory
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-202
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-202
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: MetaData
>    Affects Versions:  JBossMC_2_0_0 Beta3
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> When looking at obtaining MetaType/MetaValues for primative arrays I see problems with the primitive array type name ("[char" vs "[C") and attempts to cast to Object[] in DefaultMetaValueFactory. The referenced forum discusses the 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 lists.jboss.org  Fri Aug 10 02:24:01 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 10 Aug 2007 02:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-199) Add support
 for propagating TransientManagedObjects from structural deployers
In-Reply-To: <11389462.1185657407363.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19113685.1186727041549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-199?page=all ]

Scott M Stark updated JBMICROCONT-199:
--------------------------------------

    Comment: was deleted

> Add support for propagating TransientManagedObjects from structural deployers
> -----------------------------------------------------------------------------
>
>                 Key: JBMICROCONT-199
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-199
>             Project: JBoss MicroContainer
>          Issue Type: Feature Request
>          Components: Deployment
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> We need the ability for a structure deployer to add attachments that can be used as input to regular deployers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 04:22:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 04:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3455737.1186734121283.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371702 ] 
            
Koen Aers commented on GPD-128:
-------------------------------

John,

I would need to know what the use case of this method is. The replacement of getConfigurationElementByXmlElementName(String) has been replaced by getConfigurationElementByXmlNode(Node) as I told earlier. In what context are you using this method?

Regards,
Koen 

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Fri Aug 10 04:53:01 2007
From: jira-events at lists.jboss.org (Roland Huss (JIRA))
Date: Fri, 10 Aug 2007 04:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1036) config-type schema
 declaration doesnt accept custom instantiator classes
Message-ID: <1713438.1186735981810.JavaMail.jira@cloud.prod.atl2.jboss.com>

config-type schema declaration doesnt accept custom instantiator classes
------------------------------------------------------------------------

                 Key: JBPM-1036
                 URL: http://jira.jboss.com/jira/browse/JBPM-1036
             Project: JBoss jBPM
          Issue Type: Bug
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: Roland Huss
         Assigned To: Tom Baeyens


Specifying a custom delegation instantiator with a  fully qualified class name like in

<action config-type="com.consol.cmas.workflow.jbpm.exe.SpringInstantiator"
              class="com.consol.cmas.projects.it.workflow.development.AssignCallToReviewerActionHandler"/>
	
doesnt work anymore because the schema allows value from a fixed enumeration only:

<xs:attribute name="config-type" default="field">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="field"/>
            <xs:enumeration value="bean"/>
            <xs:enumeration value="constructor"/>
            <xs:enumeration value="configuration-property"/>
          </xs:restriction>
        </xs:simpleType>
 </xs:attribute>

This contrary to  the relevant code in the Delegation class this should work (and indeed worked in some pre 3.2.1 versions):

Instantiator instantiator = null;
    try {
      // find the instantiator
      instantiator = (Instantiator) instantiatorCache.get(configType);
      if (instantiator == null) {
        // load the instantiator class
        Class instantiatorClass = classLoader.loadClass(configType);
        // instantiate the instantiator with the default constructor
        instantiator = (Instantiator) instantiatorClass.newInstance();
        instantiatorCache.put(configType, instantiator);
      }
    } catch (Exception e) {
      log.error(e);
      throw new JbpmException("couldn't instantiate custom instantiator '" + configType + "'", e);
    }
	
So please either relax the schema restriction (which I highly prefer, since I rely on using a custom instantiator) or remove the possibility to 
use a custom instantiator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 04:57:01 2007
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 10 Aug 2007 04:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-123) Better
 mechanism to determine Array class
In-Reply-To: <29606274.1165415815779.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8238045.1186736221148.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-123?page=all ]

Ales Justin closed JBMICROCONT-123.
-----------------------------------

    Fix Version/s: JBossMC-2.0.0.Beta4
                       (was:  JBossMC-2.2.0.GA)
       Resolution: Done

See Scott's comment on the forum - 1st post 2nd page.

> Better mechanism to determine Array class
> -----------------------------------------
>
>                 Key: JBMICROCONT-123
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-123
>             Project: JBoss MicroContainer
>          Issue Type: Bug
>          Components: BeanInfo
>    Affects Versions: JBossMC_2_0_0 Beta
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>            Priority: Minor
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> The current implementation of getArrayClass uses the horrible
>    public static Class getArrayClass(Class clazz, int depth)
>    {
>       return Array.newInstance(clazz, depth).getClass();
>    }
> there must be a better way to do 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 lists.jboss.org  Fri Aug 10 05:46:01 2007
From: jira-events at lists.jboss.org (Hendra Sasmita (JIRA))
Date: Fri, 10 Aug 2007 05:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1045) Count Message
 With Selector
Message-ID: <25240548.1186739161321.JavaMail.jira@cloud.prod.atl2.jboss.com>

Count Message With Selector
---------------------------

                 Key: JBMESSAGING-1045
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1045
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Destination Manager
            Reporter: Hendra Sasmita
         Assigned To: Tim Fox
            Priority: Optional


QueueService and TopicService have methods listAllMessages with selector. This method will return list of messages.
Sometime operator / administrator wants to know only about the number of messages with certain criteria.
In this case, listAllMessages will become inefficient as it returns full list of messages, therefore another method that return the number only 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 lists.jboss.org  Fri Aug 10 05:52:01 2007
From: jira-events at lists.jboss.org (Hendra Sasmita (JIRA))
Date: Fri, 10 Aug 2007 05:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1046) Edit Messages
 inside Destination
Message-ID: <7418916.1186739521564.JavaMail.jira@cloud.prod.atl2.jboss.com>

Edit Messages inside Destination
--------------------------------

                 Key: JBMESSAGING-1046
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1046
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Destination Manager
            Reporter: Hendra Sasmita
         Assigned To: Tim Fox
            Priority: Optional


For administrative purpose, operators may want to change the message's content and/or properties.
As example, change all message that has content X, with content Y

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 05:54:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Aug 2007 05:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1045) Count Message
 With Selector
In-Reply-To: <25240548.1186739161321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10970030.1186739641094.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1045?page=all ]

Tim Fox updated JBMESSAGING-1045:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1

> Count Message With Selector
> ---------------------------
>
>                 Key: JBMESSAGING-1045
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1045
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>            Reporter: Hendra Sasmita
>         Assigned To: Tim Fox
>            Priority: Optional
>             Fix For: 2.0.0 Beta 1
>
>
> QueueService and TopicService have methods listAllMessages with selector. This method will return list of messages.
> Sometime operator / administrator wants to know only about the number of messages with certain criteria.
> In this case, listAllMessages will become inefficient as it returns full list of messages, therefore another method that return the number only 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 lists.jboss.org  Fri Aug 10 05:56:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Aug 2007 05:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1046) Edit Messages
 inside Destination
In-Reply-To: <7418916.1186739521564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2573563.1186739761117.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1046?page=all ]

Tim Fox updated JBMESSAGING-1046:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1

> Edit Messages inside Destination
> --------------------------------
>
>                 Key: JBMESSAGING-1046
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1046
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>            Reporter: Hendra Sasmita
>         Assigned To: Tim Fox
>            Priority: Optional
>             Fix For: 2.0.0 Beta 1
>
>
> For administrative purpose, operators may want to change the message's content and/or properties.
> As example, change all message that has content X, with content Y

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:28:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1047)
 ServerPeer.listMessageCountersAsHTML sorted by Name
Message-ID: <3125471.1186741681302.JavaMail.jira@cloud.prod.atl2.jboss.com>

ServerPeer.listMessageCountersAsHTML sorted by Name
---------------------------------------------------

                 Key: JBMESSAGING-1047
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1047
             Project: JBoss Messaging
          Issue Type: Patch
            Reporter: Aslak
         Assigned To: Tim Fox


Added name sort to the MessageCounter list. 

Gives a better overview when having lots of Queue/Topic/Subscriptions 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 lists.jboss.org  Fri Aug 10 06:30:01 2007
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Fri, 10 Aug 2007 06:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
Message-ID: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>

Getting exception org.apache.commons.httpclient.HttpRecoverableException
------------------------------------------------------------------------

                 Key: JBWEB-89
                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
            Reporter: Masao Kato
         Assigned To: Mladen Turk


We are getting this exception .

ERROR [org.apache.catalina.connector.CoyoteAdapter] 
java.lang.StringIndexOutOfBoundsException: String index out of range: 32
        at java.lang.String.substring(String.java:1765)
        at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
        at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
        at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
        at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)
        
I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
I made a patch. 
Is this right?

--- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
+++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
@@ -125,7 +125,7 @@
       int index = oldsessionId.lastIndexOf(".");
       if (index > 0)
       {
-         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
+         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
       }

       String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:30:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1047)
 ServerPeer.listMessageCountersAsHTML sorted by Name
In-Reply-To: <3125471.1186741681302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27683595.1186741801367.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1047?page=all ]

Aslak updated JBMESSAGING-1047:
-------------------------------

    Attachment: jmessage_1047.patch

> ServerPeer.listMessageCountersAsHTML sorted by Name
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1047
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1047
>             Project: JBoss Messaging
>          Issue Type: Patch
>            Reporter: Aslak
>         Assigned To: Tim Fox
>         Attachments: jmessage_1047.patch
>
>
> Added name sort to the MessageCounter list. 
> Gives a better overview when having lots of Queue/Topic/Subscriptions 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 lists.jboss.org  Fri Aug 10 06:32:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1047)
 ServerPeer.listMessageCountersAsHTML sorted by Name
In-Reply-To: <3125471.1186741681302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1251998.1186741921173.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1047?page=all ]

Aslak updated JBMESSAGING-1047:
-------------------------------

    Issue Type: Feature Request  (was: Patch)

> ServerPeer.listMessageCountersAsHTML sorted by Name
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1047
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1047
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Aslak
>         Assigned To: Tim Fox
>         Attachments: jmessage_1047.patch
>
>
> Added name sort to the MessageCounter list. 
> Gives a better overview when having lots of Queue/Topic/Subscriptions 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 lists.jboss.org  Fri Aug 10 06:32:01 2007
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Fri, 10 Aug 2007 06:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1672234.1186741921417.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-89?page=all ]

Masao Kato updated JBWEB-89:
----------------------------

    Attachment: patch.txt

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Mladen Turk
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:37:51 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 10 Aug 2007 06:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-140) when working with
 large process
 definitions, screen jumps to top whenever new nodes added in designer
Message-ID: <12103377.1186742271676.JavaMail.jira@cloud.prod.atl2.jboss.com>

when working with large process definitions, screen jumps to top whenever new nodes added in designer
-----------------------------------------------------------------------------------------------------

                 Key: GPD-140
                 URL: http://jira.jboss.com/jira/browse/GPD-140
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: osx macbook pro, eclipse 3.3.0, designer plugin 3.1.0 beta 1, beta 2, CR1
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Trivial


Hi,

when working with large process diagrams, if I am scrolled down to the bottom of the view, and add a new node, when the screen is updated it jumps back up to the top, so I need to scroll down again.

Obviously when adding many nodes, this costs time, its just a trivial thing.

Cheers

Ross

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:47:01 2007
From: jira-events at lists.jboss.org (Aslak (JIRA))
Date: Fri, 10 Aug 2007 06:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1042) Investigate
 possible casting issue with message bridge
In-Reply-To: <5137497.1186667449514.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11011828.1186742821301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1042?page=all ]

Aslak updated JBMESSAGING-1042:
-------------------------------

    Attachment: JBMESSAGING-1042.patch

Only set the JbossDestination on the incoming message if it is a known Message. 

Set the JbossDestination on the messageToSend if it is a foreign message (after it has been converted/copied). A Foreign message might not like JbossDestinations.


> Investigate possible casting issue with message bridge
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1042
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1042
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>         Attachments: JBMESSAGING-1042.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 lists.jboss.org  Fri Aug 10 06:50:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Fri, 10 Aug 2007 06:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23226909.1186743001356.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=comments#action_12371711 ] 
            
Antoine Herzog commented on JBPORTAL-1146:
------------------------------------------

Hi,
Thanks...

When I worked on this part, a few mounth ago, I did a enhanced export featured : 

 - it allow to export with managing the locales of the files, so to export/import without taking care of "what locale",  

 - and save the title, description... so this can be restored at the import

 - it store the extra information in some properties files, inside the zip, and the import manage to retrieve the things and restore the files in the cms

 - it is build on the same way the export/import works... just added features in some inherited/copied class.

 - the gui is using some similar/modified jsp... but the choice of one/several locale is not done (all locales always...or only one).

it was working on 2.4.1, but did not tested it on 2.6 (I am migrating things little by little on this new version).

if you think it is of any interest, I can provide all the stuff... for integration in the portal.

but I can do this only on a "as is" basis : just take the things out of my project, and send it.
(I have a huge work to do, first priority, for at least the end of august ... and then the end of the year... so can't contribute more with arranging and preparing the package for easy integration.)



> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 06:59:30 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 06:59:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16788827.1186743570198.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=comments#action_12371712 ] 
            
Thomas Heute commented on JBPORTAL-1146:
----------------------------------------

Please Antoine, keep in mind that when you contribute your work, it's there to stay.

It means that we maintain it, and you don't have to worry about merging (with potential modifications) your changes again and again across versions, so usually it worths the little extra time to get a good diff and add a little bit of configuration.

We are all extremely busy so if you send it like this it will unfortunately will probably never get integrated.

It seems that you are loosing time to migrate while you could probably move more stuff on the Portal SVN end and then not have to worry about migration.

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 07:20:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Fri, 10 Aug 2007 07:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1146)
 java.lang.NegativeArraySizeException in uploading zip archive
In-Reply-To: <32465387.1164737276450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1742107.1186744801795.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1146?page=comments#action_12371715 ] 
            
Antoine Herzog commented on JBPORTAL-1146:
------------------------------------------

ok... understood
use the tools (svn) to make it easy for everybody
I did not think of doing some of my work on my projects as a contribution... from the beginning. 
I will... and organize thing for that

sorry, also, I did not want to make an offense, saying "take this as it is... I don't want to ear about it".

I will make this for this export import feature... when I work again on that part of my project... and have put my svn in place.

> java.lang.NegativeArraySizeException in uploading zip archive
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1146
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1146
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP / JBP 2.4
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.4.2 Final, 2.6.2 Final
>
>         Attachments: StoreArchiveCommand.java
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> when uploading an archive file, there is an exception :
> java.lang.NegativeArraySizeException
>      at org.jboss.portal.cms.impl.jcr.command.StoreArchiveCommand.execute(StoreArchiveCommand.java:72)
>      at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:61)
> It is because of the zipEntry.getSize() that return -1 (unknown size).
> this is because of the use of ZipInputStream class. 
> there is a turnaround with using the ZipFile class instead.
> see : http://forum.java.sun.com/thread.jspa?threadID=492219&messageID=2316626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 07:32:01 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 07:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-141)
 IType.getCompilationUnit() can be
 null if handler class is in jar, leads to event loop exception
Message-ID: <31471639.1186745521420.JavaMail.jira@cloud.prod.atl2.jboss.com>

IType.getCompilationUnit() can be null if handler class is in jar, leads to event loop exception
------------------------------------------------------------------------------------------------

                 Key: GPD-141
                 URL: http://jira.jboss.com/jira/browse/GPD-141
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: Eclipse 3.2 on Windows 2000
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


Following part of my processdefinition.xml:
		<event type="node-leave">
			<action class="x.y.z.MyClass" name="An Action">
				<arg>
					anArg
				</arg>
			</action>
		</event>

MyClass is in a jar which is added to the classpath of the Process Project. Saving throws an event loop exception in Error Log View with the following stack.

Caused by: org.eclipse.jface.util.Assert$AssertionFailedException: null argument;
at org.eclipse.jface.util.Assert.isNotNull(Assert.java:150)
at org.eclipse.jface.util.Assert.isNotNull(Assert.java:126)
at org.eclipse.jface.viewers.StructuredViewer.assertElementsNotNull(StructuredViewer.java:577)
at org.eclipse.jface.viewers.CheckboxTreeViewer.setCheckedElements(CheckboxTreeViewer.java:431)
at org.jbpm.gd.jpdl.deployment.IncludeInDeploymentTreeViewer.setCheckedElements(IncludeInDeploymentTreeViewer.java:61)
at org.jbpm.gd.jpdl.deployment.DeploymentForm$17.run(DeploymentForm.java:635)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123)

The problem is, that DeploymentForm.getElementsToCheckFor() does not respect that MyClass returns null for getCompilationUnit(). As a consequence, setCheckedElements is called with null in the Object[].

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:36:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Aug 2007 08:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1036) config-type schema
 declaration doesnt accept custom instantiator classes
In-Reply-To: <1713438.1186735981810.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12102869.1186749378957.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1036?page=comments#action_12371723 ] 
            
Ronald van Kuijk commented on JBPM-1036:
----------------------------------------

3.1 schema also had this restriction. most likely you did not have a reference to a schema in pre 3.2 processdefinitions. If you remove de schemareference it will most likely work. So reduced to minor since there is a 'workaround' 

> config-type schema declaration doesnt accept custom instantiator classes
> ------------------------------------------------------------------------
>
>                 Key: JBPM-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1036
>             Project: JBoss jBPM
>          Issue Type: Bug
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: Roland Huss
>         Assigned To: Tom Baeyens
>
> Specifying a custom delegation instantiator with a  fully qualified class name like in
> <action config-type="com.consol.cmas.workflow.jbpm.exe.SpringInstantiator"
>               class="com.consol.cmas.projects.it.workflow.development.AssignCallToReviewerActionHandler"/>
> 	
> doesnt work anymore because the schema allows value from a fixed enumeration only:
> <xs:attribute name="config-type" default="field">
>         <xs:simpleType>
>           <xs:restriction base="xs:string">
>             <xs:enumeration value="field"/>
>             <xs:enumeration value="bean"/>
>             <xs:enumeration value="constructor"/>
>             <xs:enumeration value="configuration-property"/>
>           </xs:restriction>
>         </xs:simpleType>
>  </xs:attribute>
> This contrary to  the relevant code in the Delegation class this should work (and indeed worked in some pre 3.2.1 versions):
> Instantiator instantiator = null;
>     try {
>       // find the instantiator
>       instantiator = (Instantiator) instantiatorCache.get(configType);
>       if (instantiator == null) {
>         // load the instantiator class
>         Class instantiatorClass = classLoader.loadClass(configType);
>         // instantiate the instantiator with the default constructor
>         instantiator = (Instantiator) instantiatorClass.newInstance();
>         instantiatorCache.put(configType, instantiator);
>       }
>     } catch (Exception e) {
>       log.error(e);
>       throw new JbpmException("couldn't instantiate custom instantiator '" + configType + "'", e);
>     }
> 	
> So please either relax the schema restriction (which I highly prefer, since I rely on using a custom instantiator) or remove the possibility to 
> use a custom instantiator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:36:19 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Aug 2007 08:36:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1036) config-type schema
 declaration doesnt accept custom instantiator classes
In-Reply-To: <1713438.1186735981810.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3510148.1186749379267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1036?page=all ]

Ronald van Kuijk updated JBPM-1036:
-----------------------------------

                Issue Type: Feature Request  (was: Bug)
    Workaround Description: remove schema reference in the top of the PD.
                  Priority: Minor  (was: Major)

Oh.. and it is not a bug then, but a feature request. 

> config-type schema declaration doesnt accept custom instantiator classes
> ------------------------------------------------------------------------
>
>                 Key: JBPM-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1036
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: Roland Huss
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> Specifying a custom delegation instantiator with a  fully qualified class name like in
> <action config-type="com.consol.cmas.workflow.jbpm.exe.SpringInstantiator"
>               class="com.consol.cmas.projects.it.workflow.development.AssignCallToReviewerActionHandler"/>
> 	
> doesnt work anymore because the schema allows value from a fixed enumeration only:
> <xs:attribute name="config-type" default="field">
>         <xs:simpleType>
>           <xs:restriction base="xs:string">
>             <xs:enumeration value="field"/>
>             <xs:enumeration value="bean"/>
>             <xs:enumeration value="constructor"/>
>             <xs:enumeration value="configuration-property"/>
>           </xs:restriction>
>         </xs:simpleType>
>  </xs:attribute>
> This contrary to  the relevant code in the Delegation class this should work (and indeed worked in some pre 3.2.1 versions):
> Instantiator instantiator = null;
>     try {
>       // find the instantiator
>       instantiator = (Instantiator) instantiatorCache.get(configType);
>       if (instantiator == null) {
>         // load the instantiator class
>         Class instantiatorClass = classLoader.loadClass(configType);
>         // instantiate the instantiator with the default constructor
>         instantiator = (Instantiator) instantiatorClass.newInstance();
>         instantiatorCache.put(configType, instantiator);
>       }
>     } catch (Exception e) {
>       log.error(e);
>       throw new JbpmException("couldn't instantiate custom instantiator '" + configType + "'", e);
>     }
> 	
> So please either relax the schema restriction (which I highly prefer, since I rely on using a custom instantiator) or remove the possibility to 
> use a custom instantiator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:57:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1626) FIrst access to
 a CMS HTML file through /content/ results in a NPE
Message-ID: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>

FIrst access to a CMS HTML file through /content/ results in a NPE
------------------------------------------------------------------

                 Key: JBPORTAL-1626
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.6.1 Final
            Reporter: Thomas Heute
         Assigned To: Sohil Shah
             Fix For: 2.6.2 Final


To reproduce, after startup go to:
http://localhost:8080/portal/content/default/project.html

It will fails to acquire a read lock resulting in a null content.

It fails when trying to do:
             VersionHistory vh = contentNode.getVersionHistory();

in ContentGetCommand


On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 08:59:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 08:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5753497.1186750741317.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12371726 ] 
            
Thomas Heute commented on JBPORTAL-1626:
----------------------------------------

By the way it was working fine on 2.6.0.

I had a quick look at the diff between the 2 in cms and core-cms but couldn't spot anything obvious.

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 09:14:27 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 09:14:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
Message-ID: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jbpm.gd.common.properties should be exported in MANIFEST:MF
---------------------------------------------------------------

                 Key: GPD-142
                 URL: http://jira.jboss.com/jira/browse/GPD-142
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 09:26:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 09:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8415180.1186752361617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-142?page=comments#action_12371732 ] 
            
Koen Aers commented on GPD-142:
-------------------------------

This is part of a refactoring that will happen later. 

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 09:48:00 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 10 Aug 2007 09:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1627) Problem
 destroying service
 portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
Message-ID: <12607797.1186753680992.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1627
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1627
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Widget
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
            Priority: Minor
             Fix For: 2.6.2 Final


On AS shutdown:

Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
java.lang.reflect.UndeclaredThrowableException
        at $Proxy0.destroy(Unknown Source)
        at org.jboss.system.ServiceController.destroy(ServiceController.java:577)
        at org.jboss.system.ServiceController.shutdown(ServiceController.java:714)
        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.server.ServerImpl$ShutdownHook.shutdownServices(ServerImpl.java:1079)
        at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1037)
        at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
Caused by: javax.management.InstanceNotFoundException: portal:service=ContentRenderer,type=GoogleWidgetPortletInstance is not registered.
        at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:653)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
        ... 15 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 lists.jboss.org  Fri Aug 10 09:58:56 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 10 Aug 2007 09:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4601) Add example
 sybase-xa-ds.xml from the forums
Message-ID: <24810986.1186754336899.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add example sybase-xa-ds.xml from the forums
--------------------------------------------

                 Key: JBAS-4601
                 URL: http://jira.jboss.com/jira/browse/JBAS-4601
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JCA service
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


Add the example sybase xa configuration to docs/examples/jca

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:02:01 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 10 Aug 2007 10:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1037) process image
 rendered incorrectly for large process definition
Message-ID: <2916967.1186754521287.JavaMail.jira@cloud.prod.atl2.jboss.com>

process image rendered incorrectly for large process definition
---------------------------------------------------------------

                 Key: JBPM-1037
                 URL: http://jira.jboss.com/jira/browse/JBPM-1037
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Web Interface
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: mac osx,  tomcat 5.0.28
            Reporter: Ross McDonald
         Assigned To: Tom Baeyens
            Priority: Minor


Hi,

then I create a large process, and extend to the left beyond the original boundary, by placing and element in the designer and dragging, so scrollbars appear, the image when rendered in the console is offset incorrectly while on any given node,

cheers

Ross

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:02:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 10 Aug 2007 10:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4601) Add example
 sybase-xa-ds.xml from the forums
In-Reply-To: <24810986.1186754336899.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23019700.1186754521416.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4601?page=all ]

Adrian Brock closed JBAS-4601.
------------------------------

    Resolution: Done

> Add example sybase-xa-ds.xml from the forums
> --------------------------------------------
>
>                 Key: JBAS-4601
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4601
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> Add the example sybase xa configuration to docs/examples/jca

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:08:01 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 10 Aug 2007 10:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1037) process image
 rendered incorrectly for large process definition
In-Reply-To: <2916967.1186754521287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16990792.1186754881467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1037?page=all ]

Ross McDonald updated JBPM-1037:
--------------------------------

    Workaround Description: don't move any element in the designer beyond the original left margin

> process image rendered incorrectly for large process definition
> ---------------------------------------------------------------
>
>                 Key: JBPM-1037
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1037
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: mac osx,  tomcat 5.0.28
>            Reporter: Ross McDonald
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> Hi,
> then I create a large process, and extend to the left beyond the original boundary, by placing and element in the designer and dragging, so scrollbars appear, the image when rendered in the console is offset incorrectly while on any given node,
> cheers
> Ross

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:30:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1577) Adding a window
 is not reflected immediately
In-Reply-To: <25157575.1184332923806.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6864318.1186756201440.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1577?page=all ]

Thomas Heute resolved JBPORTAL-1577.
------------------------------------

    Resolution: Rejected

There is no way to do it so that:
- It's efficient
- Doesn't require lot of changes

This issue doesn't exist in 2.6 Branch (after lot of changes)

> Adding a window is not reflected immediately
> --------------------------------------------
>
>                 Key: JBPORTAL-1577
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1577
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.4.2 Final
>
>         Attachments: PageNavigationInterceptor.patch
>
>
> org.jboss.portal.core.aspects.controller.PagaNavigationIntercepor is caching the window context map of a page.
> The side effect is that if you dynamically add a window, you need to start a new session to see the change.
> (That issue is not 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 lists.jboss.org  Fri Aug 10 10:32:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1231) Management
 beans initialized too many times
In-Reply-To: <12447684.1170670759570.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25998596.1186756322066.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1231?page=all ]

Thomas Heute resolved JBPORTAL-1231.
------------------------------------

    Fix Version/s:     (was: 2.4.3 Final)
       Resolution: Won't Fix

> Management beans initialized too many times
> -------------------------------------------
>
>                 Key: JBPORTAL-1231
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1231
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1, 2.6.Alpha2
>         Environment: AS 4.0.5
> Portal 2.6Alpha1 or Alpha2 from svn tag
>            Reporter: Ryszard Kozmik
>         Assigned To: Julien Viet
>            Priority: Minor
>
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'portalobjectmgr' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'portalAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'addPageAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'addWindowAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'themePropertyAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'instancemgr' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'preferenceAction' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'portletmgr' - only keeping the last 
> 10:44:14,533 WARN  [FacesConfigurator] More than one managed bean w/ the name of 'createInstanceAction' - only keeping the 
> Those warnings are harmless and are caused by newer myfaces libraries in AS 4.0.5. Please look at forum link included in this task for sollution. However, this sollution might not fully work as Portal has quite old Facelets libraries.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:51:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1611)
 ActionRequest.sendRedirect() doesn't work
In-Reply-To: <14641528.1185385247142.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <430091.1186757461387.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1611?page=all ]

Thomas Heute resolved JBPORTAL-1611.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

> ActionRequest.sendRedirect() doesn't work
> -----------------------------------------
>
>                 Key: JBPORTAL-1611
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1611
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> sendRedirect() doesn't work anymore on an actionRequest.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:53:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1612) Let the user
 specify a redirection on the signout URL mapping
In-Reply-To: <23128939.1185385374886.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29245726.1186757582810.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1612?page=all ]

Thomas Heute resolved JBPORTAL-1612.
------------------------------------

    Resolution: Done

> Let the user specify a redirection on the signout URL mapping
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1612
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1612
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 10:59:15 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 10 Aug 2007 10:59:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1590)
 org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager trace
 log action prints permission type
In-Reply-To: <22703648.1184661407170.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17974515.1186757955550.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1590?page=all ]

Thomas Heute resolved JBPORTAL-1590.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

> org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager trace log action prints permission type
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1590
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1590
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.6 Final
>            Reporter: Juergen none
>         Assigned To: Thomas Heute
>            Priority: Trivial
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager::checkPermission() trace log prints permission.getType() for action
> should probably be permission.getName() ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:07:02 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 10 Aug 2007 11:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4600) Rename JBossMQ
 variables from
 jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into
 build-thirdparty
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6475663.1186758422564.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4600?page=all ]

Clebert Suconic closed JBAS-4600.
---------------------------------

    Resolution: Done

> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:21:29 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 11:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29717368.1186759289656.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-142?page=comments#action_12371747 ] 
            
Koen Aers commented on GPD-142:
-------------------------------

oh, i did not see the title... i will do this rightaway

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 11:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10420391.1186759381047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-142?page=all ]

Koen Aers closed GPD-142.
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:31:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 10 Aug 2007 11:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-111) Add ability to forward
 and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16155815.1186759861233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Koen Aers updated GPD-111:
--------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
                       (was: jBPM JPDL Designer 3.1.0.CR)

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:38:36 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-142)
 org.jbpm.gd.common.properties should be exported in MANIFEST:MF
In-Reply-To: <4984551.1186751667021.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <823047.1186760316698.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-142?page=comments#action_12371749 ] 
            
Matthias Hanisch commented on GPD-142:
--------------------------------------

Thanks. Another diff is gone :).

> org.jbpm.gd.common.properties should be exported in MANIFEST:MF
> ---------------------------------------------------------------
>
>                 Key: GPD-142
>                 URL: http://jira.jboss.com/jira/browse/GPD-142
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> ... to be able to use AbstractPropertySection in dependent plugins.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:54:13 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Fri, 10 Aug 2007 11:54:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-143) Load the icon of a
 paletteContribution entry from the plugin directory where it is defined
Message-ID: <28132773.1186761253835.JavaMail.jira@cloud.prod.atl2.jboss.com>

Load the icon of a paletteContribution entry from the plugin directory where it is defined
------------------------------------------------------------------------------------------

                 Key: GPD-143
                 URL: http://jira.jboss.com/jira/browse/GPD-143
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Matthias Hanisch
         Assigned To: Koen Aers


In PaletteRoot class, the icon of a palette entry is always loaded from org.jbpm.gd.jpdl plugin, even if the paletteContribution entry is defined in a dependent plugin.
The information, where the palette entry element (entryElement in PaletteRoot.addControls) is defined, can be found in entryElement.getContributor().getName().
So also the corresponding image can be loaded from the correct bundle.

[ Sorry to only give a verbal description of the implementation. I would sign a corporate contributor's agreement, but I have problems with the procedure, e.g.
- do we need a corporate jboss account for my boss to sign
- if we sign with the "corporate" account, with which account I need to contribute then
etc.
So I would need some assistance here. Then you would get a real diff also.
]


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 11:56:03 2007
From: jira-events at lists.jboss.org (=?UTF-8?Q?Roland_R=C3=A4z_=28JIRA=29?=)
Date: Fri, 10 Aug 2007 11:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4602)
 org.jboss.deployment.DeploymentException is thrown when configuring the
 ServerSocketFactory attribute of the NamingService
Message-ID: <19579224.1186761363641.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.deployment.DeploymentException is thrown when configuring the ServerSocketFactory attribute of the NamingService
--------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4602
                 URL: http://jira.jboss.com/jira/browse/JBAS-4602
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Roland R?z


The following exception is thrown when the ServerSocketFactory attribute is configured in the org.jboss.naming.NamingService MBean is configured:

16:09:01,948 INFO  [ServiceConfigurator] Problem configuring service jboss:service=Naming
org.jboss.deployment.DeploymentException: No property editor for attribute: ServerSocketFactory; type=interface java.rmi.server.RMIServerSocketFactory
        at org.jboss.system.ServiceConfigurator.parseTextSerialData(ServiceConfigurator.java:554)
        at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:329)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
        at org.jboss.system.ServiceController.install(ServiceController.java:226)
        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)
...


Reason:

The file conf/xmdesc/NamingService-xmbean.xml contains a second definition of the ServerSocketFactory attribute ServerSocketFactory. The second definition should be ServerSocketFactoryBean.

Snippet from NamingService-xmbean.xml:

<attribute access="read-write" getMethod="getServerSocketFactory" setMethod="setServerSocketFactory">
 <description>The RMI service java.rmi.server.RMIServerSocketFactory class name</description>
 <name>ServerSocketFactory</name>
 <type>java.lang.String</type>
</attribute>
<attribute access="read-write" getMethod="getServerSocketFactoryBean" setMethod="setServerSocketFactoryBean">
 <description>The RMI service java.rmi.server.RMIServerSocketFactory instance</description>
 <name>ServerSocketFactory</name>
 <type>java.rmi.server.RMIServerSocketFactory</type>
</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 lists.jboss.org  Fri Aug 10 11:58:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 10 Aug 2007 11:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-105) switch from oswego to
 java.util concurrent
Message-ID: <23612134.1186761481061.JavaMail.jira@cloud.prod.atl2.jboss.com>

switch from oswego to java.util concurrent
------------------------------------------

                 Key: JBXB-105
                 URL: http://jira.jboss.com/jira/browse/JBXB-105
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Task
    Affects Versions:  JBossXB-2.0.0.CR2, JBossXB-1.0.0.CR10
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky
             Fix For: JBossXB-1.0.0.CR11, JBossXB-2.0.0.CR3


It was decided to move away from the oswego to java.util concurrent package, make XB build with Java5 compiler and use retroweaver if java1.4 binary compliance 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 lists.jboss.org  Fri Aug 10 12:07:01 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 10 Aug 2007 12:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-105) GossipRouter should
 additionally listen on IP multicast group and bridge traffic
Message-ID: <539632.1186762021339.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-105?page=comments#action_12371759 ] 
            
Galder Zamarreno commented on JGRP-105:
---------------------------------------

Looking at JBCACHE-816, I spotted some potential requirements 
for JGRP-105 as explained in:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4073104#4073104

Note: DC refers to Data Centre as indicated in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheAcrossDataCentres

Summarised requirements:

- be able to filter which traffic get's propagated to DCs, i.e. only JBC 
CRUD methods (put, remove...etc). JGroups could define an interface 
for that, which JBC would implement based on its requirements.

- configurable (sync/async) communications for in DC (typically IP multicast and 
synchronous) and inter DC (inter GR - typically TCP based and asynchronous)

- GR failover. We need to support failover of a GR so that another node in the 
local DC takes over. 

> GossipRouter should additionally listen on IP multicast group and bridge traffic
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-105
>                 URL: http://jira.jboss.com/jira/browse/JGRP-105
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> GossipRouter should be augmented to not just route traffic between TCP endpoints, but also between an IP multicast group and all TCP endpoints.
> It should be configured with the properties for a (multicast-based) group X, and then forward messages from X to all of its attached endpoints, and vice versa.
> In the future, this concept could be extended to generic bridging functionality, which will allow to construct hierarchical messaging trees, similar to the MBone

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 12:12:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 10 Aug 2007 12:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-105) switch from oswego to
 java.util concurrent
In-Reply-To: <23612134.1186761481061.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24917355.1186762321079.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-105?page=all ]

Alexey Loubyansky closed JBXB-105.
----------------------------------

    Resolution: Done

Done.

> switch from oswego to java.util concurrent
> ------------------------------------------
>
>                 Key: JBXB-105
>                 URL: http://jira.jboss.com/jira/browse/JBXB-105
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-1.0.0.CR10,  JBossXB-2.0.0.CR2
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR11, JBossXB-2.0.0.CR3
>
>
> It was decided to move away from the oswego to java.util concurrent package, make XB build with Java5 compiler and use retroweaver if java1.4 binary compliance 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 lists.jboss.org  Fri Aug 10 12:30:01 2007
From: jira-events at lists.jboss.org (Jaya prakash (JIRA))
Date: Fri, 10 Aug 2007 12:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4603) How to Find out
 client login time,logout time and what he did in JBoss log
Message-ID: <27906119.1186763401140.JavaMail.jira@cloud.prod.atl2.jboss.com>

How to Find out client login time,logout time and what he did in JBoss log
--------------------------------------------------------------------------

                 Key: JBAS-4603
                 URL: http://jira.jboss.com/jira/browse/JBAS-4603
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Jaya prakash
            Priority: Blocker


Here i am facing the issue to find out the user(client) log-in time and log-out time, If he done any thing what he done. I searched in log file but i didn't find out that clearly .

Please advise me.

Regards,
Red 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 12:46:08 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Fri, 10 Aug 2007 12:46:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14612950.1186764368765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371763 ] 
            
John Ruud commented on GPD-128:
-------------------------------

Koen,

I used to add a child element to a SemanticElement by passing in the element-name of the child. Looking at this again I suspect I should just use parentNode.getFactory().createById(), passing in the element id instead, right? (not sure why I didn't do this in the first place)

Thanks, John

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Fri Aug 10 13:49:01 2007
From: jira-events at lists.jboss.org (Steven Holmes (JIRA))
Date: Fri, 10 Aug 2007 13:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-253) Throwing an
 exception when adding a category or forum on 2.6.1 and 4.2
Message-ID: <33225614.1186768141443.JavaMail.jira@cloud.prod.atl2.jboss.com>

Throwing an exception when adding a category or forum on 2.6.1 and 4.2
----------------------------------------------------------------------

                 Key: JBFORUMS-253
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-253
             Project: JBoss Forums
          Issue Type: Bug
          Components: Forum View Layer
    Affects Versions: 1.0.0 GA
         Environment: 2.6.1 on 4.2 on Windows XP Pro
            Reporter: Steven Holmes
         Assigned To: Ryszard Kozmik


It is throwing a funny exception whenever I add a category or forum in admin mode.  The exception appears to be the same regardless of whether I am adding a forum or category.
I got the following exception when I was trying to add my first Category:

ERROR
Cause: javax.portlet.PortletException: javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
Message: javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
StackTrace:

javax.portlet.PortletException: javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:367)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:397)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(TransactionInterceptor.java:106)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeRequired(TransactionInterceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:80)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
	at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
	at sun.reflect.GeneratedMethodAccessor353.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:99)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
	at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
	at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
	at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
	at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:116)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
	at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
	at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
	at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
	at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
	at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
	at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
	at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
	at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
	at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:595)
javax.portlet.PortletException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:254)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:400)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:363)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:397)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(TransactionInterceptor.java:106)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeRequired(TransactionInterceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:80)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
	at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
	at sun.reflect.GeneratedMethodAccessor353.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:99)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
	at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
	at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
	at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
	at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:116)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
	at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
	at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
	at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
	at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
	at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
	at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
	at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
	at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
	at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:595)
java.lang.IllegalStateException: Client-id : jbpns_2fdefault_2fforums_2fJBossForumsWindowsnpbj_id79 is duplicated in the faces tree.
	at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:241)
	at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
	at org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:204)
	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:554)
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:352)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:396)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:363)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
	at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:397)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
	at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(TransactionInterceptor.java:106)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRequired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103964459766407072.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeRequired(TransactionInterceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java:80)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
	at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
	at sun.reflect.GeneratedMethodAccessor353.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:99)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
	at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
	at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
	at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
	at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:116)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8654503705355129869.java)
	at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
	at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
	at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
	at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
	at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
	at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
	at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
	at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
	at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
	at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
	at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
	at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
	at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
	at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	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.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
	at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
	at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	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 lists.jboss.org  Fri Aug 10 14:34:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Fri, 10 Aug 2007 14:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-472) Release JBoss Cache
	2.0
Message-ID: <15978620.1186770841216.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-472?page=all ]

Manik Surtani closed JBCACHE-472.
---------------------------------

    Resolution: Done

> Release JBoss Cache 2.0
> -----------------------
>
>                 Key: JBCACHE-472
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-472
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.GA
>            Reporter: Manik Surtani
>         Assigned To: Ryan Campbell
>             Fix For: 2.0.0.GA
>
>
> Add all release tasks here (docos, tutorials, dr through to rc, 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 lists.jboss.org  Fri Aug 10 14:40:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 10 Aug 2007 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1031) Potential
 bug in cancelling delivery
In-Reply-To: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25037834.1186771201149.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1031?page=all ]

Clebert Suconic reassigned JBMESSAGING-1031:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Potential bug in cancelling delivery
> ------------------------------------
>
>                 Key: JBMESSAGING-1031
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 16:32:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Aug 2007 16:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1044) Cleanup docs
 using xml editor
In-Reply-To: <5895634.1186684741257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12467704.1186777921081.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1044?page=all ]

Tim Fox updated JBMESSAGING-1044:
---------------------------------

    Fix Version/s: 1.4.0.GA
                       (was: 1.4.0.CR2)

> Cleanup docs using xml editor
> -----------------------------
>
>                 Key: JBMESSAGING-1044
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1044
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 17:00:01 2007
From: jira-events at lists.jboss.org (Przemyslaw Dej (JIRA))
Date: Fri, 10 Aug 2007 17:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-250) Posts created by
 Anonymous user cause problems.
In-Reply-To: <8514775.1184854073939.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24836000.1186779601417.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-250?page=all ]

Przemyslaw Dej resolved JBFORUMS-250.
-------------------------------------

    Resolution: Done

> Posts created by Anonymous user cause problems.
> -----------------------------------------------
>
>                 Key: JBFORUMS-250
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-250
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Forum View Layer, Forum Model Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Przemyslaw Dej
>             Fix For: 1.0.1 RC
>
>          Time Spent: 3 days
>
> Please read forum reference for more information about the 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 lists.jboss.org  Fri Aug 10 20:09:19 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 10 Aug 2007 20:09:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-322) Allow the
 conversion of normal Java projects to Drools projects
Message-ID: <30533971.1186790959692.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-322?page=all ]

Kris Verlaenen updated JBRULES-322:
-----------------------------------

    Fix Version/s: 4.0.1
                       (was: 3.1-m1)

Added a better implementation, you can now just right-click the (Java)Project and execute the Convert action.
Also first checks whether the necessary elements are already added or not.

> Allow the conversion of normal Java projects to Drools projects
> ---------------------------------------------------------------
>
>                 Key: JBRULES-322
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-322
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.1
>            Reporter: Kris Verlaenen
>         Assigned To: Kris Verlaenen
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Allow the conversion of normal Java projects to Drools projects, preferable as a menu item when right-clicking a (non-drools Java) 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 lists.jboss.org  Fri Aug 10 21:18:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1068) Exception when
 adding
 "activation-group" attribute to otherwise correctly executed rule...
In-Reply-To: <25370522.1186685101163.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11523833.1186795081403.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1068?page=comments#action_12371786 ] 
            
Mark Proctor commented on JBRULES-1068:
---------------------------------------

there should be no = on activation group. Although the error feedback is not good.
activation-group "unique-solution"

> Exception when adding "activation-group" attribute to otherwise correctly executed rule...
> ------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1068
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1068
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> rule "Golfer-Riddle with a single solution?" 
> 	activation-group="unique-solution"
>     when
>         // There is a golfer names Fred, 
>         $f: Golfer( name == "Fred",
> ...
> yields:
> Exception in thread "main" org.drools.compiler.DroolsParserException: Unknown error while parsing. This is a bug. Please contact the Development team.
> 	at org.drools.compiler.DrlParser.compile(DrlParser.java:180)
> 	at org.drools.compiler.DrlParser.parse(DrlParser.java:61)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:19)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:18:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1068) Better error
 handling for incorrect chars with rule attributes
In-Reply-To: <25370522.1186685101163.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21093645.1186795081613.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1068?page=all ]

Mark Proctor updated JBRULES-1068:
----------------------------------

          Summary: Better error handling for incorrect chars with rule attributes  (was: Exception when adding "activation-group" attribute to otherwise correctly executed rule...)
    Fix Version/s: FUTURE

> Better error handling for incorrect chars with rule attributes
> --------------------------------------------------------------
>
>                 Key: JBRULES-1068
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1068
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> rule "Golfer-Riddle with a single solution?" 
> 	activation-group="unique-solution"
>     when
>         // There is a golfer names Fred, 
>         $f: Golfer( name == "Fred",
> ...
> yields:
> Exception in thread "main" org.drools.compiler.DroolsParserException: Unknown error while parsing. This is a bug. Please contact the Development team.
> 	at org.drools.compiler.DrlParser.compile(DrlParser.java:180)
> 	at org.drools.compiler.DrlParser.parse(DrlParser.java:61)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:19)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:20:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
In-Reply-To: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20820214.1186795201222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1070?page=all ]

Mark Proctor updated JBRULES-1070:
----------------------------------

    Fix Version/s: 4.0.1

> Exception with "not in" condition with  (int-values)
> ----------------------------------------------------
>
>                 Key: JBRULES-1070
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> // Bob wears plaid       
> Golfer( name == "Bob", 
>         $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
>         $bobsColor : color == "plaid",
>         color != $fredsColor, color != $joesColor,
>         color != $fredsNeighbourColor )
> yields the following exception
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
> 	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:22:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
In-Reply-To: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4448230.1186795321407.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1072?page=comments#action_12371787 ] 
            
Mark Proctor commented on JBRULES-1072:
---------------------------------------

There has been a url change and infrastructure have not got redirects working yet :( If you go to the main drools home page now and navigate to the docs page you'll see it does have the correct docs:
http://labs.jboss.com/drools/docs/index.html

the build.xml files no longer exist as we are totally mavenised now.

> Installation / Build instructions do not match what SVN delivers
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1072
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP on Dell desktop
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>
> Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.
> There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.
> Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
> C:\dev\jbossrules\drools-eclipse>ant clean-all
> Buildfile: build.xml
> BUILD FAILED
> Target "clean-all" does not exist in the project "Build All Elements".
> Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
> eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.
> Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 10 21:22:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 10 Aug 2007 21:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1072) Installation /
 Build instructions do not match what SVN delivers
In-Reply-To: <24462346.1186692181214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8469151.1186795321589.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1072?page=all ]

Mark Proctor closed JBRULES-1072.
---------------------------------

    Resolution: Won't Fix

There isn't anything I can do here, have to wait for IT to setup redirects.

> Installation / Build instructions do not match what SVN delivers
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1072
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1072
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP on Dell desktop
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>
> Documentation for building from source (http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/ch02s04.html) indicates that 'ant' can be run from the root of the project. However there is no build.xml file in the root.
> There are build.xml files in drools-eclipse, drools-jbrms, drools-examples-drl, and documentation.
> Going to drools-eclipse and running: ant clean-all  (as inferred from the doc) [or 'ant build-all'] we get
> C:\dev\jbossrules\drools-eclipse>ant clean-all
> Buildfile: build.xml
> BUILD FAILED
> Target "clean-all" does not exist in the project "Build All Elements".
> Just running 'ant': Gets Build successful in 1 second. Under target subdirectory are 
> eclipse.build/features, eclipse.build/maps, eclipse.build/plugins, eclipse.build/N.drools.build, but all are empty.
> Proceeded to documentation build, which seems to have been successful in 1 Min and 1 Sec. Will see if that manual has any hints.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 05:15:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sat, 11 Aug 2007 05:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-128) ClassCastException in
 XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
In-Reply-To: <11208106.1186179289389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23779107.1186823701113.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-128?page=comments#action_12371789 ] 
            
Koen Aers commented on GPD-128:
-------------------------------

Yes that is correct. 

Don't worry, I regularly make similar mistakes ;-)

Cheers,
Koen

> ClassCastException in XmlAdapterFactory.getConfigurationElementByXmlElementName(String)
> ---------------------------------------------------------------------------------------
>
>                 Key: GPD-128
>                 URL: http://jira.jboss.com/jira/browse/GPD-128
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>
> I just noticed this problem in the current HEAD (so not in the official 3.1.0.CR release, I think). In XmlAdapterFactory (1.2), a TreeSet (as opposed to a IConfigurationElement) is now returned under certain conditions, and this causes a ClassCastException to be thrown (and this is breaking some of my exsiting 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 lists.jboss.org  Sat Aug 11 12:46:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 11 Aug 2007 12:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5205841.1186850761659.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=comments#action_12371795 ] 
            
Mark Proctor commented on JBRULES-1056:
---------------------------------------

I'm not seeing this with code in trunk. I changed the iteration in "run" from 3 to 20 and asked it to do 200 packages and go the following output:
Added 200 packages to rulebase1 in 0.375 seconds
Added 200 packages to rulebase2 in 0.141 seconds
Added 200 packages to rulebase3 in 0.125 seconds
Added 200 packages to rulebase4 in 0.172 seconds
Added 200 packages to rulebase5 in 0.125 seconds
Added 200 packages to rulebase6 in 0.125 seconds
Added 200 packages to rulebase7 in 0.125 seconds
Added 200 packages to rulebase8 in 0.156 seconds
Added 200 packages to rulebase9 in 0.172 seconds
Added 200 packages to rulebase10 in 0.109 seconds
Added 200 packages to rulebase11 in 0.109 seconds
Added 200 packages to rulebase12 in 0.125 seconds
Added 200 packages to rulebase13 in 0.11 seconds
Added 200 packages to rulebase14 in 0.109 seconds
Added 200 packages to rulebase15 in 0.125 seconds
Added 200 packages to rulebase16 in 0.219 seconds
Added 200 packages to rulebase17 in 0.094 seconds
Added 200 packages to rulebase18 in 0.125 seconds
Added 200 packages to rulebase19 in 0.109 seconds
Added 200 packages to rulebase20 in 0.109 seconds

Is there something I'm not getting, or not running the test correctly?
Bits I changed are:
    public void run() throws Exception {
        List drls = generateDrls();
        List pkgs = generatePackages( drls );

        for ( int i = 0; i < 20; i++ ) {
            addPackages( pkgs,
                         i + 1 );
        }
    }


    public static void main(String[] argv) throws Exception {
        if ( argv.length > 0 ) {
            try {
                new TestDrools( Integer.parseInt( argv[0] ) ).run();
            } catch ( Exception ex ) {
                ex.printStackTrace();
            }
        } else { //System.out.println( "Usage: TestDrool [# of packages]" );
            new TestDrools( 200 ).run();
        }
    }

If I am running the test correctly and my results are ok,  can I please ask you to test trunk using the snapshot builds here:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sat Aug 11 12:56:03 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 12:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27691797.1186851363330.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=all ]

Edson Tirelli reassigned JBRULES-1060:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Sat Aug 11 13:34:05 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 11 Aug 2007 13:34:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1059) Online typos in
	Section 1
In-Reply-To: <15111425.1186340029389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14798915.1186853645306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1059?page=all ]

Mark Proctor closed JBRULES-1059.
---------------------------------

    Resolution: Done

> Online typos in Section 1
> -------------------------
>
>                 Key: JBRULES-1059
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1059
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: n/a  - concerns documentation availble for viewing over internet
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> miscellaneous typos
> http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/4.0.0.12865MR3/html/index.html
> Section 1.1
> modiied ? modified
> Drools will adding ? Drools will be adding
> Section 1.2.1
> explination ? explanation
> layed ? laid
> espically ? especially
> knowlegde ? knowledge
> Section 1.2.4
> preceeding ? preceding
> its ? it's
> Section 1.3.1
> shortley ? shortly
> Section 1.3.2
> conjuntive ? conjunctive
> disjuntive ? disjunctive
> Section 1.6.1
> grammer ? grammar
> deployeable ? deployable
> PackagBuilder ? PackageBuilder
> Section 1.6.4.6
> In the shaded box, should 'new List' simply be 'List' ?
> Section 1.6.5
> legible ? eligible
> section 1.6.6.1
> managable ? manageable
> section 1.6.7
> AgendEventListener ? AgendaEventListener

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 14:35:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1073)
 CompositeContextEntry is raising NPE
Message-ID: <15185920.1186857301091.JavaMail.jira@cloud.prod.atl2.jboss.com>

CompositeContextEntry is raising NPE
------------------------------------

                 Key: JBRULES-1073
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1073
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


Stack Trace:

Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromFactHandle(AbstractCompositeRestriction.java:104)
	at org.drools.common.DoubleBetaConstraints.updateFromFactHandle(DoubleBetaConstraints.java:138)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:308)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:850)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:824)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:625)
	at org.drools.examples.GolfingExample.main(GolfingExample.java:32)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 14:37:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 14:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1073)
 CompositeContextEntry is raising NPE
In-Reply-To: <15185920.1186857301091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8993213.1186857421131.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1073?page=all ]

Edson Tirelli resolved JBRULES-1073.
------------------------------------

    Resolution: Done

Problem was a mistake in the constructor where an incorrect variable declaration was shadowing the instance attribute:

    public static class CompositeContextEntry
        implements
        ContextEntry {
        public ContextEntry[] contextEntries;

        private ContextEntry  entry;

        public CompositeContextEntry(final Restriction[] restrictions) {
            final ContextEntry[] contextEntries = new ContextEntry[restrictions.length];
            for ( int i = 0; i < restrictions.length; i++ ) {
                contextEntries[i] = restrictions[i].getContextEntry();
            }
        }

Fixed.

> CompositeContextEntry is raising NPE
> ------------------------------------
>
>                 Key: JBRULES-1073
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1073
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Stack Trace:
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromFactHandle(AbstractCompositeRestriction.java:104)
> 	at org.drools.common.DoubleBetaConstraints.updateFromFactHandle(DoubleBetaConstraints.java:138)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:308)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:850)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:824)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:625)
> 	at org.drools.examples.GolfingExample.main(GolfingExample.java:32)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 14:39:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 14:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1073)
 CompositeContextEntry is raising NPE
In-Reply-To: <15185920.1186857301091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19309383.1186857541071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1073?page=all ]

Edson Tirelli closed JBRULES-1073.
----------------------------------


> CompositeContextEntry is raising NPE
> ------------------------------------
>
>                 Key: JBRULES-1073
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1073
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Stack Trace:
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromFactHandle(AbstractCompositeRestriction.java:104)
> 	at org.drools.common.DoubleBetaConstraints.updateFromFactHandle(DoubleBetaConstraints.java:138)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:158)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:308)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:850)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:824)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:625)
> 	at org.drools.examples.GolfingExample.main(GolfingExample.java:32)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 11 15:44:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Aug 2007 15:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3771739.1186861441213.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=comments#action_12371800 ] 
            
Edson Tirelli commented on JBRULES-1056:
----------------------------------------

Mark,

I'm seeing the behavior both on 4.0GA and trunk. Doing a quick profiling, seems the reason is the PackageCompilationData.write() method:

    public void write(final String resourceName,
                      final byte[] clazzData) throws RuntimeDroolsException {
        if ( this.store.put( resourceName,
                             clazzData ) != null ) {
            // we are updating an existing class so reload();
            reload();
        } else {
            try {
                wire( convertResourceToClassName( resourceName ) );
            } catch ( final Exception e ) {
                e.printStackTrace();
                throw new RuntimeDroolsException( e );
            }
        }
    }

    The first time a rule base is loaded, the classes are generated and loaded, but from the second time and on, as the class already exists, the reload() method is called, and it seems to be quite heavy:

    public void reload() throws RuntimeDroolsException {
        // drops the classLoader and adds a new one
        this.classLoader = new PackageClassLoader( this.parentClassLoader );

        // Wire up invokers
        try {
            for ( final Iterator it = this.invokerLookups.keySet().iterator(); it.hasNext(); ) {
                wire( (String) it.next() );
            }
        } catch ( final ClassNotFoundException e ) {
            throw new RuntimeDroolsException( e );
        } catch ( final InstantiationError e ) {
            throw new RuntimeDroolsException( e );
        } catch ( final IllegalAccessException e ) {
            throw new RuntimeDroolsException( e );
        } catch ( final InstantiationException e ) {
            throw new RuntimeDroolsException( e );
        }
    }

    Profiling is charging up to 50% of run time to that method when running that test.

    Seems we need to either make this method lighter or at least check and only reload if the bytecodes actually change....


> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 05:03:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 05:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8527132.1186909381368.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=comments#action_12371803 ] 
            
Mark Proctor commented on JBRULES-1056:
---------------------------------------

Why didn't it show up in my test results?

Yes due to java issues on the classloader it does a reload() if thet classname already exists.. However that should not have something that gets increasingly worse, maybe a slightly heaver hit the second time, but should be the same for each consecutive time after that. I guess with MVEL in reflection mode this shouldn't be an issue, so that may be a work around from now. If a rule is being reloaded what are the chances the byte[] hasn't changed?

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 05:05:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 05:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7107784.1186909501108.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=comments#action_12371804 ] 
            
Mark Proctor commented on JBRULES-1056:
---------------------------------------

just had a thought, if you have 200 classes its going to drop and reload 200 times. However the reload only needs to happen once. So the answer is to some how have a callback so reload only happens at the end, maybe even on the first working memory action....

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 05:54:01 2007
From: jira-events at lists.jboss.org (Lior Ban (JIRA))
Date: Sun, 12 Aug 2007 05:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1025) When running
 HBM2DDL on
 StringInstnace.hbm.xml on oracle DB, the length of the column length is 255
 even that it defined 4000 in hbm
In-Reply-To: <33100434.1185195227128.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16459037.1186912441197.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1025?page=comments#action_12371805 ] 
            
Lior Ban commented on JBPM-1025:
--------------------------------

There is a solution to this, the file StringInstance.hbm.xml can be changed as follow to support this:

<?xml version="1.0"?>

<!DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD 3.0//EN" 
    "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping default-access="field">

  <subclass name="org.jbpm.context.exe.variableinstance.StringInstance" 
            extends="org.jbpm.context.exe.VariableInstance" 
            discriminator-value="S">
    <property name="value" type="string" column="STRINGVALUE_" length="4000"/>
  </subclass>
  
  <database-object>
    <create>
       ALTER TABLE "JBPM_VARIABLEINSTANCE" MODIFY "STRINGVALUE_" varchar(4000)  
    </create>
    <drop></drop>  
    <dialect-scope name="org.hibernate.dialect.SybaseAnywhereDialect"></dialect-scope>
  </database-object>
  
  <database-object>  
    <create>  
       ALTER TABLE jbpm_variableinstance MODIFY COLUMN STRINGVALUE_ VARCHAR(4000)  
    </create>  
    <drop></drop>  
    <dialect-scope name="org.hibernate.dialect.MySQLDialect"></dialect-scope>  
    <dialect-scope name="org.hibernate.dialect.DB2Dialect"></dialect-scope>  
    <dialect-scope name="org.hibernate.dialect.OracleDialect"></dialect-scope>  
  </database-object>

</hibernate-mapping>



> When running HBM2DDL on StringInstnace.hbm.xml on oracle DB, the length of the column length is 255 even that it defined 4000 in hbm
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1025
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1025
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: Oracle on Unix Solaris
>            Reporter: Lior Ban
>         Assigned To: Tom Baeyens
>
> We create the Oracle JBPM DB tables by running Hbm2Ddl,
> In the StringInstance.hbm.xml file it is writen:
> <property name="value" type="string" length="4000">
> However still when creating the DB in the DB explorer we see that it is VARCHAR2(255) length 255
> Maybe it is veacuse setValue and getValue return object in VarilableInstance object from which StringInstance inherits?
> When we have string with length 269 it can't be put in the DB and we get 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 lists.jboss.org  Sun Aug 12 09:23:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1074) Support the use
 of Integer, Float, Short and Byte in accumulate functions
Message-ID: <14718682.1186924981314.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support the use of Integer, Float, Short and Byte in accumulate functions
-------------------------------------------------------------------------

                 Key: JBRULES-1074
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1074
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Edson Tirelli
            Priority: Minor
             Fix For: 4.0.1


Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 10:14:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 10:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1074) Support the use
 of Integer, Float, Short and Byte in accumulate functions
In-Reply-To: <14718682.1186924981314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15676478.1186928041213.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1074?page=comments#action_12371806 ] 
            
Geoffrey De Smet commented on JBRULES-1074:
-------------------------------------------

The value in this signature is always a Long, even if it's an Integer:

public void accumulate(Object context,
                           Object value) {

> Support the use of Integer, Float, Short and Byte in accumulate functions
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1074
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1074
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 10:25:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 10:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1075) Support
 overloading of
 accumulate functions: Add int (or long) based sum's, int based avarage's,
 etc
Message-ID: <28273319.1186928701233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc 
-----------------------------------------------------------------------------------------------------

                 Key: JBRULES-1075
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1075
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Edson Tirelli
            Priority: Minor
             Fix For: FUTURE


TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:

1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.

2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
 sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
 sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.

And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
  sum($myString)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 10:28:06 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 12 Aug 2007 10:28:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1075) Support
 overloading of
 accumulate functions: Add int (or long) based sum's, int based avarage's,
 etc
In-Reply-To: <28273319.1186928701233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9551504.1186928886812.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1075?page=all ]

Geoffrey De Smet updated JBRULES-1075:
--------------------------------------

    Attachment: JBRULES-1075.patch

> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc 
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1075
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1075
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: FUTURE
>
>         Attachments: JBRULES-1075.patch
>
>
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
>  sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
>  sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
>   sum($myString)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 14:12:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 12 Aug 2007 14:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-382) Remove Complex
 Advice Signatures from Classic Mode
In-Reply-To: <23885199.1176740459311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4211957.1186942321253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-382?page=all ]

Stale Pedersen resolved JBAOP-382.
----------------------------------

    Resolution: Done

fix commited. needs revision and a we need to decide if the tests should be removed or moved.

> Remove Complex Advice Signatures from Classic Mode
> --------------------------------------------------
>
>                 Key: JBAOP-382
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-382
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We need to update PerVMAdvice class, to remove the possibility of advices that receive joinpoint arguments (currently, the matching of parameters is not completely functional).
> We will leave the possibility of receiving joinpoint arguments as parameters to the annotated-parameters signature.
> This task also includes moving arg tests to beforeafterArgs package.
> PS: documentation is already stating that only annotated-parameters advice signatures can feature joinpoint arguments as parameters. No need to update documentation here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 14:23:01 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Sun, 12 Aug 2007 14:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
Message-ID: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>

Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
------------------------------------------------------------------------------

                 Key: JBRULES-1076
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.MR3
         Environment: WinXP
            Reporter: Dave Dibble
         Assigned To: Mark Proctor
            Priority: Trivial


Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"

Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:

C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
[INFO] Scanning for projects...
[INFO] -------------------------------------------------------------------------
---
[INFO] Building Maven Default Project
[INFO]    task-segment: [clean, install]
[INFO] -------------------------------------------------------------------------
---
[INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
s from central
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
plugin/2.1.1/maven-clean-plugin-2.1.1.pom
1K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
s/3/maven-plugins-3.pom
6K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
-parent-4.pom
9K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
3K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
plugin/2.1.1/maven-clean-plugin-2.1.1.jar
6K downloaded
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
l, but the build is not using one.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5 seconds
[INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
[INFO] Final Memory: 1M/4M
[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 lists.jboss.org  Sun Aug 12 15:43:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Sun, 12 Aug 2007 15:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-200) Make sure the
 batch and sh files work
Message-ID: <26720424.1186947781275.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-200?page=comments#action_12371810 ] 
            
Stale Pedersen commented on JBAOP-200:
--------------------------------------

hm, one problem is that the .sh files are packages with dos encoding. the result is that those files will not run with "./run-load15.sh", and if you try "sh run-load15.sh" it would run, but also give a lot of errors and just die before doing anything.
- tested with 2.0.0alpha5.

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 12 17:22:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 17:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27646950.1186953721321.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=comments#action_12371812 ] 
            
Mark Proctor commented on JBRULES-1056:
---------------------------------------

I see the test only does the first part, not the second part of re-adding rules to the same rulebase. I've updated the test as follows:
    public void run() throws Exception {
        List drls = generateDrls();
        List pkgs = generatePackages( drls );

        double time = 0;
        for ( int i = 0; i < 20; i++ ) {            
            time += addPackages( pkgs,
                         RuleBaseFactory.newRuleBase(),
                         i + 1 );
        }
        System.out.println( "average time " + (time/20.0) + " seconds.\n\n" );
        
        time = 0;
        RuleBase rb = RuleBaseFactory.newRuleBase();
        for ( int i = 0; i < 20; i++ ) {            
            time += addPackages( pkgs,
                         rb,
                         i + 1 );
        }                
        System.out.println( "average time " + (time/20.0) + " seconds." );               
    }

    private static double addPackages(List pkgs,
                                        RuleBase rb,
                                        int id) throws Exception {
        double start = System.currentTimeMillis();
        for ( Iterator it = pkgs.iterator(); it.hasNext(); ) {
            Package pkg = (Package) it.next();
            rb.addPackage( pkg );
        }
        double time = (System.currentTimeMillis() - start) / 1000.0;
        System.out.println( "Added " + pkgs.size() + " packages to rulebase" + id + " in " + time + " seconds" );
        return time;
    }

and I get the following time outputs:
Added 200 packages to rulebase1 in 0.219 seconds
Added 200 packages to rulebase2 in 0.125 seconds
Added 200 packages to rulebase3 in 0.14 seconds
Added 200 packages to rulebase4 in 0.141 seconds
Added 200 packages to rulebase5 in 0.125 seconds
Added 200 packages to rulebase6 in 0.109 seconds
Added 200 packages to rulebase7 in 0.125 seconds
Added 200 packages to rulebase8 in 0.156 seconds
Added 200 packages to rulebase9 in 0.172 seconds
Added 200 packages to rulebase10 in 0.11 seconds
Added 200 packages to rulebase11 in 0.093 seconds
Added 200 packages to rulebase12 in 0.125 seconds
Added 200 packages to rulebase13 in 0.11 seconds
Added 200 packages to rulebase14 in 0.109 seconds
Added 200 packages to rulebase15 in 0.125 seconds
Added 200 packages to rulebase16 in 0.203 seconds
Added 200 packages to rulebase17 in 0.094 seconds
Added 200 packages to rulebase18 in 0.109 seconds
Added 200 packages to rulebase19 in 0.109 seconds
Added 200 packages to rulebase20 in 0.125 seconds
average time 0.13119999999999998 seconds.


Added 200 packages to rulebase1 in 0.125 seconds
Added 200 packages to rulebase2 in 0.11 seconds
Added 200 packages to rulebase3 in 0.125 seconds
Added 200 packages to rulebase4 in 0.172 seconds
Added 200 packages to rulebase5 in 0.109 seconds
Added 200 packages to rulebase6 in 0.109 seconds
Added 200 packages to rulebase7 in 0.11 seconds
Added 200 packages to rulebase8 in 0.109 seconds
Added 200 packages to rulebase9 in 0.125 seconds
Added 200 packages to rulebase10 in 0.125 seconds
Added 200 packages to rulebase11 in 0.172 seconds
Added 200 packages to rulebase12 in 0.109 seconds
Added 200 packages to rulebase13 in 0.094 seconds
Added 200 packages to rulebase14 in 0.125 seconds
Added 200 packages to rulebase15 in 0.109 seconds
Added 200 packages to rulebase16 in 0.11 seconds
Added 200 packages to rulebase17 in 0.109 seconds
Added 200 packages to rulebase18 in 0.188 seconds
Added 200 packages to rulebase19 in 0.109 seconds
Added 200 packages to rulebase20 in 0.094 seconds
average time 0.12190000000000001 seconds.

Interestingly I still don't get a difference, what are you guys doing differently?

Anyway the code currently is still inefficient due to the constant reload() call, so I'll fix that anyway and hopefully it will fix the issue that everyone else is getting.

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 21:51:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Sun, 12 Aug 2007 21:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1077) Decision tables
 to have ruleflow-group attribute column
Message-ID: <30015767.1186969861144.JavaMail.jira@cloud.prod.atl2.jboss.com>

Decision tables to have ruleflow-group attribute column
-------------------------------------------------------

                 Key: JBRULES-1077
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1077
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Fernando Meyer
            Priority: Minor
             Fix For: 4.0.1


In decision tables, we can set no-loop attributes (amongst others) by haveing a special keyword in a column (chekc the code for how this is done). Would like to add ruleflow-group to this 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 lists.jboss.org  Sun Aug 12 23:32:12 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 23:32:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent
 instances of RuleBase with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26809361.1186975932760.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=comments#action_12371817 ] 
            
Mark Proctor commented on JBRULES-1056:
---------------------------------------

new code is in so that the reload() is delayed to the first workingmemoryaction, this should really help situations where you are reloading existing rules. My results also show that standard Package loading is faster too, although not exactly sure why....
Added 200 packages to rulebase1 in 0.031 seconds
Added 200 packages to rulebase2 in 0.016 seconds
Added 200 packages to rulebase3 in 0.016 seconds
Added 200 packages to rulebase4 in 0.016 seconds
Added 200 packages to rulebase5 in 0.0 seconds
Added 200 packages to rulebase6 in 0.016 seconds
Added 200 packages to rulebase7 in 0.0 seconds
Added 200 packages to rulebase8 in 0.031 seconds
Added 200 packages to rulebase9 in 0.0 seconds
Added 200 packages to rulebase10 in 0.0 seconds
Added 200 packages to rulebase11 in 0.0 seconds
Added 200 packages to rulebase12 in 0.015 seconds
Added 200 packages to rulebase13 in 0.0 seconds
Added 200 packages to rulebase14 in 0.0 seconds
Added 200 packages to rulebase15 in 0.016 seconds
Added 200 packages to rulebase16 in 0.0 seconds
Added 200 packages to rulebase17 in 0.0 seconds
Added 200 packages to rulebase18 in 0.0 seconds
Added 200 packages to rulebase19 in 0.0 seconds
Added 200 packages to rulebase20 in 0.0 seconds
average time 0.007850000000000001 seconds.


Added 200 packages to rulebase1 in 0.0 seconds
Added 200 packages to rulebase2 in 0.0 seconds
Added 200 packages to rulebase3 in 0.015 seconds
Added 200 packages to rulebase4 in 0.0 seconds
Added 200 packages to rulebase5 in 0.0 seconds
Added 200 packages to rulebase6 in 0.0 seconds
Added 200 packages to rulebase7 in 0.0 seconds
Added 200 packages to rulebase8 in 0.0 seconds
Added 200 packages to rulebase9 in 0.016 seconds
Added 200 packages to rulebase10 in 0.0 seconds
Added 200 packages to rulebase11 in 0.0 seconds
Added 200 packages to rulebase12 in 0.0 seconds
Added 200 packages to rulebase13 in 0.0 seconds
Added 200 packages to rulebase14 in 0.015 seconds
Added 200 packages to rulebase15 in 0.0 seconds
Added 200 packages to rulebase16 in 0.0 seconds
Added 200 packages to rulebase17 in 0.0 seconds
Added 200 packages to rulebase18 in 0.0 seconds
Added 200 packages to rulebase19 in 0.016 seconds
Added 200 packages to rulebase20 in 0.0 seconds
average time 0.0031 seconds.

Anyway its looking good I think. please try out the snapshot build and make sure this works for both of you.

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: testdrools.zip
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Sun Aug 12 23:35:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Aug 2007 23:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29200891.1186976101116.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=all ]

Mark Proctor updated JBRULES-1056:
----------------------------------

    Attachment: TestDrools.java
                TestObject.java

Just uploading the files I used to test it with.

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: TestDrools.java, testdrools.zip, TestObject.java
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Mon Aug 13 01:15:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 13 Aug 2007 01:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1027) unable to use
 moderately complicated expression in from
In-Reply-To: <9849857.1185356991161.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13062392.1186982101202.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1027?page=comments#action_12371820 ] 
            
Michael Neale commented on JBRULES-1027:
----------------------------------------

Yes I think the fix was in MVEL since this bug was raised, shoudl be all cool now. Was certainly an MVEL not a rule grammar problem. 

> unable to use moderately complicated expression in from
> -------------------------------------------------------
>
>                 Key: JBRULES-1027
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1027
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> Try the following fairly simple example, and an error will ensue: 
> package sample;
> import Query;
> import Results;
> import Storage;
> rule "Verify_1"
>     when
>         content : Storage()
>         results : Results( ) from content.search(new Query("test","field"))
>     then
>         System.out.println( results ); 
> end
> ============================================================================
> /**
>  * 
>  */
> public class Query {
>     public Query(String pattern, String column) {
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Results {
>     public int getResultsCount() {
>         return 1;
>     }
> }
> ============================================================================
> /**
>  * 
>  */
> public class Storage {
>     public Results search(Query query) {
>         return new Results();
>     }
> }
> ============================================================================
> public class HelloWorldExample {
>     public static final void main(final String[] args) throws Exception {
>         BasicConfigurator.configure();
>         Logger.getRootLogger().setLevel(Level.DEBUG);
>         DrlParser parser = new DrlParser();
>         final Reader source = new FileReader("sample.drl");
>         PackageDescr descr = parser.parse(source);
>         source.close();
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackage(descr);
>         Package pkg = builder.getPackage();
>         pkg.checkValidity();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 05:20:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 05:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6577034.1186996801090.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371826 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Matthew,

This is not a good way of implementing it. The adapters *have* to be created in the 'createAdapter' method per the specification of the AbstractAdapterFactory class. I will try to come up with an alternative solution.

Regards,
Koen

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 06:09:15 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 06:09:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22223202.1186999755707.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371831 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Hm, this looks indeed like a problem. Doing it before the createAdapter method is called looks like the only solution. I have modified your fix slightly so that the createAdapter method is nevertheless called again after the creation of the adapter. Let me know if it works.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 06:19:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 13 Aug 2007 06:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-20) Address translation in
 transport (NAT support)
Message-ID: <610892.1187000341308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-20?page=all ]

Bela Ban updated JGRP-20:
-------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

May not be needed anymore, together with logical addresses

> Address translation in transport (NAT support)
> ----------------------------------------------
>
>                 Key: JGRP-20
>                 URL: http://jira.jboss.com/jira/browse/JGRP-20
>             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
>
> On multi-homed systems, the identity of a member is bound to a NIC (either chosen by the OS, or by the
> user through bind_addr): Address. When a message is sent, the msg contains this address as the sender's
> address. Responses go to the same address.
> However, if that NIC breaks, and the sender's OS chooses a different NIC for the datagram packets, the
> receiver will still send the response back to the old address (the identity of the sender cannot
> change).
> If we set the sender's address in any Message on *reception* of the message, we would be able to send
> the response back to a valid NIC in the above case. However, this means the *identity* of the sender
> changes, which JGroups cannot handle.
> SOLUTION I: we could introduce a logical address, which contains the physical address of the NIC
> through which it was sent. Problem: a lot of code would have to change.
> SOLUTION II: we maintain, in each transport, a table of sender's address as defined in the Message, and
> physical address of the {Datagram,Multicast}Packet received. Whenever we send a unicast message, we get
> the destination address from this table through a lookup in which dest_msg.dest_addr is the key.
> We need to reap the table every now and then to purge old addresses, we could use view changes to do
> so.
> Example for SOLUTION II:
> - Member P: address=1.2.3.4:5555
> - P's box has 2 NICs: 1.2.3.4 and 5.6.7.8
> - Receiver R receives a message from P: P.src_addr=1.2.3.4:5555, datagram's address is 1234:5555
> - R doesn't add an entry to the translation table, because the addresses are the same
> - R sends a response: it looks up 1.2.3.4:5555 (dst) in the translation table
> - There is no entry, therefore R sends the response to 1.2.3.4:5555
> - P's NIC 1.2.3.4 is unplugged
> - P sends a message through NIC 5.6.7.8
> - R receives a message M.src_addr=1.2.3.4:5555, datagram's address is 5.6.7.8:5555
> - R adds an entry to its translation table: 1.2.3.4:5555 --> 5.6.7.8:5555
> - R sends a response to 1.2.3.4:5555, since there is an entry for 1.2.3.4:5555, it uses 5.6.7.8:5555 
>   as the destination address of the datagram packet
> SOLUTION II allows us to reuse the existing code, but provides for changing underlying IP addresses.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:12:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 13 Aug 2007 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-4603) How to Find out
 client login time,logout time and what he did in JBoss log
Message-ID: <12408349.1187003521102.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4603?page=all ]

Dimitris Andreadis deleted JBAS-4603:
-------------------------------------


> How to Find out client login time,logout time and what he did in JBoss log
> --------------------------------------------------------------------------
>
>                 Key: JBAS-4603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4603
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>            Reporter: Jaya prakash
>            Priority: Blocker
>
> Here i am facing the issue to find out the user(client) log-in time and log-out time, If he done any thing what he done. I searched in log file but i didn't find out that clearly .
> Please advise me.
> Regards,
> Red 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:35:01 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Mon, 13 Aug 2007 07:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27641857.1187004901200.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371844 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Hi Koen,
by accident I stumbled over the same problem today.
Your patch does not work completey in my case because you do not set the factory before you call adapt().
As a consequence XMLAdapter.isAdapterFor(type) fails, because the factory is null.
So probably you have to call setFactory() twice - once before and once after calling adapt().


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:47:01 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Mon, 13 Aug 2007 07:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9560310.1187005621247.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371846 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Ok, putting another setFactory() before adapt() call in XMLAdapterFactory.createAdapter() makes my use case work.

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 07:49:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7103361.1187005741468.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12371847 ] 
            
Koen Aers commented on GPD-78:
------------------------------

John & Imran,

I have just committed some changes that are supposed to fix this. Can you check if it works and report back?

Regards,
Koen

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Mon Aug 13 08:13:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 08:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28997687.1187007181059.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371851 ] 
            
Koen Aers commented on GPD-111:
-------------------------------

Matthias, I have simply *moved* the setFactory() before adapt(). Does that work as well?


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 08:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12332686.1187007781072.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371852 ] 
            
Koen Aers commented on GPD-138:
-------------------------------

Hi Ross,

I can't reproduce this bug. Probably I am not exactly doing the same thing as you do, so could you please describe step by step the manipulations you do. What mouseclicks on what panels, etc.
It doesn't look like an OSX problem, though it could be one. So if anyone has the same problem on a Windows or Linux machine, please join in.
Ross, I believe there was a forum post about this as well. Can you do an update of this post to ask anyone else to report?

Regards,
Koen

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Mon Aug 13 08:33:01 2007
From: jira-events at lists.jboss.org (Przemyslaw Dej (JIRA))
Date: Mon, 13 Aug 2007 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-2) Search Engine
Message-ID: <5001745.1187008381789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-2?page=all ]

Przemyslaw Dej reassigned JBFORUMS-2:
-------------------------------------

    Assignee: Przemyslaw Dej  (was: Ryszard Kozmik)

> Search Engine
> -------------
>
>                 Key: JBFORUMS-2
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-2
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum View Layer, Forum Enhancements, Forum Model Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Przemyslaw Dej
>            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 lists.jboss.org  Mon Aug 13 08:35:00 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Aug 2007 08:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-137) problem configuriing
	exception class
In-Reply-To: <7080582.1186577089238.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10909987.1187008500998.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-137?page=all ]

Koen Aers closed GPD-137.
-------------------------

    Resolution: Done

> problem configuriing exception class
> ------------------------------------
>
>                 Key: GPD-137
>                 URL: http://jira.jboss.com/jira/browse/GPD-137
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:37:01 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Mon, 13 Aug 2007 08:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1078) Allow static
 expressions in value restrictions
Message-ID: <2496000.1187008621204.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow static expressions in value restrictions
----------------------------------------------

                 Key: JBRULES-1078
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1078
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Alexandre Gattiker
         Assigned To: Mark Proctor


Would it be possible to allow the following two rules to work? In 4.0.0.GA, I get parsing errors for both.

rule "sample rule 1"
	when
		Object(toString == String.valueOf("196071"))
	then
		System.out.println("ok");
end

rule "sample rule 2"
	when
		Object(toString == new String("196071"))
	then
		System.out.println("ok");
end		

(In my particular case, I need to compare BigDecimal values).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:41:02 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Mon, 13 Aug 2007 08:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33461354.1187008862691.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371854 ] 
            
Matthew Sandoz commented on GPD-111:
------------------------------------

Koen, sorry I just couldnt find any other way to make it work. Your update works just fine for me now though. I am creating nodes as well as saving and loading them all correctly. This supports the use cases I have so far and I am closing the issue. Thanks!


> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:41:03 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Mon, 13 Aug 2007 08:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-111) Add ability to forward
 and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26447600.1187008863126.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-111?page=all ]

Matthew Sandoz closed GPD-111.
------------------------------

    Resolution: Done

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:41:03 2007
From: jira-events at lists.jboss.org (Matthias Hanisch (JIRA))
Date: Mon, 13 Aug 2007 08:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-111) Add ability to
 forward and
 reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
In-Reply-To: <17285442.1183065839688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1313091.1187008863400.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-111?page=comments#action_12371855 ] 
            
Matthias Hanisch commented on GPD-111:
--------------------------------------

Yes it works, because in my case the "result" object returned by adapt() is identical to the one created before.

I just want to note, that - with this change - you expect that adapt() returns a well configured adapter, which is probably correct.

To make it short, I am happy with this change :).

> Add ability to forward and reverse map Semantic Elements to/from Dom Node/Xml Adapters jpdl
> -------------------------------------------------------------------------------------------
>
>                 Key: GPD-111
>                 URL: http://jira.jboss.com/jira/browse/GPD-111
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: all? :)
>            Reporter: Matthew Sandoz
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: solution.zip, solution.zip, solution.zip
>
>
> Addresses need to add new semantic elements without adding new xml types. Current mapping forces 1-1 mapping between them. 
> this change allows one-to-many mapping between elements by introducing a mapping object for each semantic element. 
> this mapping object's responsibility is to determine if a chunk of xml should map to a semantic element and xml adapter or not. 
> the xml adapter registry holds a set of these mappers and loops through them all, giving each a chance to accept the xml chunk. all accepting 
> mappers are then sorted by priority and the lowest priority number is selected. mappings with no priority are given Integer.MAX priority. Mappings with 
> no mapperClass are given a default mapper class of ConfiguredSemanticElementDomMapper so that existing plugin.xml should continue to function 
> normally.
> The priority property allows the maintainer of the plugin.xml to change priorities for different circumstances, giving different potentially conflicting mappers
> a specific preference order.
> Details of change:
> Added two elements to xmlMappings.exsd: mapperClass and mapperClassPriority
> Created interface SemanticElementDomMapper to determine if a given Dom Node can be assigned to a semantic element
> Created class ConfiguredSemanticElementDomMapper as a base implementation of the SemanticElementDomMapper. This
> default implementation checks the current configured xml node name against the node name of the passed Dom Node. This should
> duplicate the existing functionality for existing standard jpdl xml node types.
> JythonNodeDomMapper is included as an example but should not be committed to the project as it is for specialized use.
> XmlAdapterRegistry constructs a HashMap of Mappers and has a new getConfigurationElementByNode method.
> XmlAdapter has 2 lines modified in the createSemanticElementFor method to use the new registry method.
> XmlAdapterFactory has modifications in createAdapter and createAdapterFromModel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:48:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Aug 2007 08:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-200) Make sure the
 batch and sh files work
Message-ID: <27829646.1187009281275.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-200?page=comments#action_12371856 ] 
            
Kabir Khan commented on JBAOP-200:
----------------------------------

So fix the encoding :-)

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:52:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Aug 2007 08:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-382) Remove Complex
 Advice Signatures from Classic Mode
In-Reply-To: <23885199.1176740459311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25305106.1187009521430.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-382?page=comments#action_12371857 ] 
            
Kabir Khan commented on JBAOP-382:
----------------------------------

Just move args to only run with generatedadvisors, i.e move it from base-tests.xml to the loadtime and compile-time generated adviosr test targets in build-tests-jdk14.xml and build-tests-jdk50.xml

> Remove Complex Advice Signatures from Classic Mode
> --------------------------------------------------
>
>                 Key: JBAOP-382
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-382
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We need to update PerVMAdvice class, to remove the possibility of advices that receive joinpoint arguments (currently, the matching of parameters is not completely functional).
> We will leave the possibility of receiving joinpoint arguments as parameters to the annotated-parameters signature.
> This task also includes moving arg tests to beforeafterArgs package.
> PS: documentation is already stating that only annotated-parameters advice signatures can feature joinpoint arguments as parameters. No need to update documentation here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:57:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 13 Aug 2007 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1078) Allow static
 expressions in value restrictions
In-Reply-To: <2496000.1187008621204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4597997.1187009821161.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1078?page=comments#action_12371858 ] 
            
Mark Proctor commented on JBRULES-1078:
---------------------------------------

4.0 will already compare BigDecimals for you, it will always attempt to coerce the values into appropriate formats. The comparison you are trying to do will need to use a return value field constraint, just wrpa it in paranthesis pair of brackets.
Object(toString == ( String.valueOf("196071") ) ) 

> Allow static expressions in value restrictions
> ----------------------------------------------
>
>                 Key: JBRULES-1078
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1078
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexandre Gattiker
>         Assigned To: Mark Proctor
>
> Would it be possible to allow the following two rules to work? In 4.0.0.GA, I get parsing errors for both.
> rule "sample rule 1"
> 	when
> 		Object(toString == String.valueOf("196071"))
> 	then
> 		System.out.println("ok");
> end
> rule "sample rule 2"
> 	when
> 		Object(toString == new String("196071"))
> 	then
> 		System.out.println("ok");
> end		
> (In my particular case, I need to compare BigDecimal values).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 08:57:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 13 Aug 2007 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1078) Allow static
 expressions in value restrictions
In-Reply-To: <2496000.1187008621204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4898260.1187009821322.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1078?page=all ]

Mark Proctor closed JBRULES-1078.
---------------------------------

    Resolution: Rejected

no bug is given here, this was really a user mailing list Q.

> Allow static expressions in value restrictions
> ----------------------------------------------
>
>                 Key: JBRULES-1078
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1078
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Alexandre Gattiker
>         Assigned To: Mark Proctor
>
> Would it be possible to allow the following two rules to work? In 4.0.0.GA, I get parsing errors for both.
> rule "sample rule 1"
> 	when
> 		Object(toString == String.valueOf("196071"))
> 	then
> 		System.out.println("ok");
> end
> rule "sample rule 2"
> 	when
> 		Object(toString == new String("196071"))
> 	then
> 		System.out.println("ok");
> end		
> (In my particular case, I need to compare BigDecimal values).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:06:03 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 13 Aug 2007 10:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-4600) Rename JBossMQ
 variables from
 jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into
 build-thirdparty
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1425653.1187013963347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4600?page=all ]

Dimitris Andreadis reopened JBAS-4600:
--------------------------------------

             
I'm ok with the messaging-mq property rename:

-         <path refid="jboss.messaging.classpath"/>
+         <path refid="jboss.messaging-mq.classpath"/> 

But I don't think we need JBM in Branch_4_2, if it's not used there. I'm thinking of possibly reverting those two:

- the inclusion of JBM in build-thirdparty.xml, and the new target in build-distr.xml
- altering conf/login-config.xml and installing messaging users/roles by default, even if it is not used.

We'll discuss this in an email thread.


> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:49:01 2007
From: jira-events at lists.jboss.org (Rakesh Ajmera (JIRA))
Date: Mon, 13 Aug 2007 10:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1628) Portal bridge
	upgrade
Message-ID: <17053523.1187016541409.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portal bridge upgrade
---------------------

                 Key: JBPORTAL-1628
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1628
             Project: JBoss Portal
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.1 SP1
            Reporter: Rakesh Ajmera


There is a new version of portal-bridge available 1.0.3(http://portals.apache.org/bridges/download.html). What's the plan of upgrading jboss portal to the latest version of portal bridge?

We need the bug fixes available in this 1.0.3 release, but it doesn't work with the jboss's portal-bridge-lib.jar that is packaged with jboss portal.   We are using Struts bridge, that is dependent on the portals-bridges-common.jar, which in turn works with JBoss's potal-bridge-lib.jar. I upgraded the portal-bridges-common.jar with the latest version, but it didn't work with portal-bridge-lib.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 lists.jboss.org  Mon Aug 13 10:54:01 2007
From: jira-events at lists.jboss.org (Marcel Lanz (JIRA))
Date: Mon, 13 Aug 2007 10:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1038) getNodeTypes() and
 getNodeNames() are switched in org.jbpm.graph.node.NodeTypes
Message-ID: <6208587.1187016841947.JavaMail.jira@cloud.prod.atl2.jboss.com>

getNodeTypes() and getNodeNames() are switched in org.jbpm.graph.node.NodeTypes
-------------------------------------------------------------------------------

                 Key: JBPM-1038
                 URL: http://jira.jboss.com/jira/browse/JBPM-1038
             Project: JBoss jBPM
          Issue Type: Bug
    Affects Versions: jBPM jPDL 3.2
            Reporter: Marcel Lanz
         Assigned To: Tom Baeyens
            Priority: Minor


getNodeTypes() is returning nodeNames and getNodeNames() returns the nodeTypes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:54:03 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 10:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1616) Portal link
 should redirect to the default page of the default portal
In-Reply-To: <29869829.1185805429311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32195823.1187016843677.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1616?page=all ]

Thomas Heute resolved JBPORTAL-1616.
------------------------------------

    Resolution: Done

> Portal link should redirect to the default page of the default portal
> ---------------------------------------------------------------------
>
>                 Key: JBPORTAL-1616
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1616
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 10:54:04 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 10:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1324) Multiple
 portals / custom url : set the default portal name
In-Reply-To: <14061068.1174504436638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21215025.1187016844081.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1324?page=all ]

Thomas Heute resolved JBPORTAL-1324.
------------------------------------

    Resolution: Done

> Multiple portals / custom url : set the default portal name
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1324
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1324
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: JBoss Portal 2.4.0 final
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Here the code of the jmx service class
> public class ConfigurableDefaultPortalCommandFactory extends
> 		DefaultPortalCommandFactory {
> 	private static final Log logger = LogFactory
> 			.getLog(ConfigurableDefaultPortalCommandFactory.class);
> 	/**
> 	 * The JMX attribute for default portal name.
> 	 */
> 	private String defaultPortalName;
> 	/**
> 	 * 
> 	 */
> 	public ConfigurableDefaultPortalCommandFactory() {
> 		super();
> 	}
> 	/*
> 	 * (non-Javadoc)
> 	 * 
> 	 * @see org.jboss.portal.core.model.portal.DefaultPortalCommandFactory#doMapping(org.jboss.portal.server.ServerInvocation,
> 	 *      java.lang.String, java.lang.String)
> 	 */
> 	public ControllerCommand doMapping(ServerInvocation invocation,
> 			String portalContextPath, String portalRequestPath) {
> 		// orginal code : ControllerCommand cmd =
> 		// nextFactory.doMapping(invocation,
> 		ControllerCommand cmd = getNextFactory().doMapping(invocation,
> 				portalContextPath, portalRequestPath);
> 		if (cmd == null) {
> 			// orginal code : Context ctx = container.getContext();
> 			Context ctx = getContainer().getContext();
> 			if (ctx == null) {
> 				throw new IllegalStateException(
> 						"Default context does not exist");
> 			}
> 			// orginal code : Portal portal = ctx.getDefaultPortal();
> 			PortalObject portalObject = ctx.getChild(getDefaultPortalName());
> 			if (portalObject == null) {
> 				throw new IllegalStateException(
> 						"PortalObject as Default Portal is not found. Default Portal name is defined to : "
> 								+ getDefaultPortalName());
> 			}
> 			Portal portal = null;
> 			if (portalObject instanceof Portal) {
> 				portal = (Portal) portalObject;
> 			} else {
> 				throw new IllegalStateException(
> 						"Can't find PortalObject with default portal name : "
> 								+ getDefaultPortalName());
> 			}
> 			// if (portal == null) {
> 			// throw new IllegalStateException("Default portal does not exist");
> 			// }
> 			Page page = portal.getDefaultPage();
> 			if (page == null) {
> 				throw new IllegalStateException("Default page does not exist");
> 			}
> 			String handle = page.getId();
> 			cmd = new RenderPageCommand(handle);
> 		}
> 		return cmd;
> 	}
> 	/**
> 	 * The JMX attribute for default portal name.
> 	 * 
> 	 * @return the defaultPortalName
> 	 */
> 	public String getDefaultPortalName() {
> 		return this.defaultPortalName;
> 	}
> 	/**
> 	 * The JMX attribute for default portal name.
> 	 * 
> 	 * @param defaultPortalName
> 	 *            the defaultPortalName to set
> 	 */
> 	public void setDefaultPortalName(String defaultPortalName) {
> 		this.defaultPortalName = defaultPortalName;
> 	}
> 	/**
> 	 * Call the super method first, then check the {@link #defaultPortalName} is
> 	 * not null and not "". Throw an exception if so.
> 	 */
> 	protected void createService() throws Exception {
> 		super.createService();
> 		if (getDefaultPortalName() == null
> 				|| getDefaultPortalName().compareTo("") == 0) {
> 			throw new Exception(
> 					"The attribute DefaultPortalName can't be null or empty string. Set it in the JMX service descriptor.");
> 		}
> 	}
> 	/*
> 	 * (non-Javadoc)
> 	 * 
> 	 * @see org.jboss.system.ServiceMBeanSupport#startService()
> 	 */
> 	@Override
> 	protected void startService() throws Exception {
> 		logger.info(this.getName() + " service starting. Default portal name : getDefaultPortalName() = "+getDefaultPortalName());
> 		super.startService();
> 	}
> 	/*
> 	 * (non-Javadoc)
> 	 * 
> 	 * @see org.jboss.system.ServiceMBeanSupport#stopService()
> 	 */
> 	@Override
> 	protected void stopService() throws Exception {
> 		super.stopService();
> 		logger.info(this.getName() + " service stoping.");
> 	}
> }
> And add the attribute in the jmx service descriptor :
> <!-- Default portal name : "default" is the default for native jboss portal (downloaded version). -->
> <attribute name="DefaultPortalName">MyDefaultPortalNameHere</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 lists.jboss.org  Mon Aug 13 10:58:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 10:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1628) Portal bridge
	upgrade
In-Reply-To: <17053523.1187016541409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26583356.1187017081051.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1628?page=all ]

Thomas Heute updated JBPORTAL-1628:
-----------------------------------

      Component/s: Portal Core
    Fix Version/s: 2.4.2 Final
                   2.6.2 Final
                   2.8 Final

> Portal bridge upgrade
> ---------------------
>
>                 Key: JBPORTAL-1628
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1628
>             Project: JBoss Portal
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 SP1
>            Reporter: Rakesh Ajmera
>             Fix For: 2.4.2 Final, 2.8 Final, 2.6.2 Final
>
>
> There is a new version of portal-bridge available 1.0.3(http://portals.apache.org/bridges/download.html). What's the plan of upgrading jboss portal to the latest version of portal bridge?
> We need the bug fixes available in this 1.0.3 release, but it doesn't work with the jboss's portal-bridge-lib.jar that is packaged with jboss portal.   We are using Struts bridge, that is dependent on the portals-bridges-common.jar, which in turn works with JBoss's potal-bridge-lib.jar. I upgraded the portal-bridges-common.jar with the latest version, but it didn't work with portal-bridge-lib.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 lists.jboss.org  Mon Aug 13 11:55:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 11:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1325)
 ConsumerCacheInterceptor : should not use the cache just after login
In-Reply-To: <23196461.1174510488890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13238247.1187020501563.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1325?page=comments#action_12371887 ] 
            
Thomas Heute commented on JBPORTAL-1325:
----------------------------------------

Antoine, did you check on 2.6 ?
I'm not sure i understood your issue, so i cannot try it myself.

> ConsumerCacheInterceptor : should not use the cache just after login
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1325
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1325
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: jbp 2.4.0
>            Reporter: Antoine Herzog
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Use case : 
>  - user come to the site. 
>  - Portlet show views for unchecked user. These views are put in the cache.
>  - user log in, let's say as admin
>  - the cached views still show the previous things, not taking into account the change of authorizations
>  - the user can't see the proper things
> usual needs :
>  - for I18n portals : change of locale when user log in. all the portlets must do the change, not depending on cache
>  - for admin or special roles features in the  portlet views
>  - for modes depending on roles (see forum post)
> In the default portal, there are no use of cache. so all these use cases are fullfiled.
> to reproduce the problem : 
>  - put some cache on the user portlet (great feature for prod), the user portlet window may not update after logging.
> resolution :
> in the ConsumerCacheInterceptor
> the CacheKey do not take into account the login state.
> see : public CacheKey(StateString navigationalState, WindowState windowState, Mode mode)
> so store the user name (or "unchecked") in the CacheEntry.
> put the parameter "userOfFragment" in the CacheKey.
> when retrieving the CacheEntry, compare the currentUser and the userOfFragment, and don't use the cache if different.
> just to see : can we have access to the logued user in this interceptor ? (that, i don't know)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 11:57:43 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 11:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28920754.1187020663917.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12371888 ] 
            
Thomas Heute commented on JBPORTAL-1499:
----------------------------------------

Sohil, Antoine,

What's the conclusion of this ?

> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:16:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1029) Deadlock in
 messaging postoffice
In-Reply-To: <28783104.1186597549324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12745859.1187021761298.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1029?page=all ]

Tim Fox closed JBMESSAGING-1029.
--------------------------------

    Resolution: Done

> Deadlock in messaging postoffice
> --------------------------------
>
>                 Key: JBMESSAGING-1029
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1029
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-603) Performance
	graphs
In-Reply-To: <23921338.1160165441490.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4319572.1187021881257.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-603?page=all ]

Tim Fox updated JBMESSAGING-603:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Performance graphs
> ------------------
>
>                 Key: JBMESSAGING-603
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-603
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>             Fix For: Unscheduled
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-718) Define
 performance criteria for Remoting
In-Reply-To: <22264608.1167850659041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4033902.1187021881457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-718?page=all ]

Tim Fox updated JBMESSAGING-718:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Define performance criteria for Remoting
> ----------------------------------------
>
>                 Key: JBMESSAGING-718
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-718
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>             Fix For: Unscheduled
>
>
> Tom Elrod: Another thing I think we need to work out is some kind of criteria for knowing when remoting has reached the performance level required for messaging.  Currently I have no way of knowing at what point remoting would be sufficiently 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 lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-942) Performance
	comparisons
In-Reply-To: <2148587.1176983619628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27388237.1187021881651.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-942?page=all ]

Tim Fox updated JBMESSAGING-942:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Performance comparisons
> -----------------------
>
>                 Key: JBMESSAGING-942
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-942
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>             Fix For: Unscheduled
>
>
> We need to make perfomance comparisons between JBR and MINA.
> Also between JBM and ActiveMQ and QPid

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 12:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 13 Aug 2007 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-412) Please use
 build.properties
 for jboss.home in examples and the auto-install script
Message-ID: <11332775.1187021881821.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-412?page=all ]

Tim Fox updated JBMESSAGING-412:
--------------------------------

    Assignee:     (was: Sergey Koshcheyev)

> Please use build.properties for jboss.home in examples and the auto-install script
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-412
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-412
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Build System
>            Reporter: Michael Yuan
>            Priority: Minor
>             Fix For: 2.0.0 Beta 1
>
>
> Right now, the build relies on JBOSS_HOME system variable. It is not the way most other projects do and it is broken on Mac. I would suggest to use a build.properties file in the root of the distribution. It has a jboss.home property that the user can edit. The user edits it once and can then use all ant tasks (auto install, examples etc.) in 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 lists.jboss.org  Mon Aug 13 13:02:01 2007
From: jira-events at lists.jboss.org (zhou guangzhao (JIRA))
Date: Mon, 13 Aug 2007 13:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1039) OutOfMemoryError
 While using multi h:selectOneRaido in dataform with multy columns
Message-ID: <21038826.1187024521208.JavaMail.jira@cloud.prod.atl2.jboss.com>

OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns
----------------------------------------------------------------------------------

                 Key: JBPM-1039
                 URL: http://jira.jboss.com/jira/browse/JBPM-1039
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Web Interface
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: jBPM 3.2.1     Tomcat 6.0.14
            Reporter: zhou guangzhao
         Assigned To: Tom Baeyens


The following taskform code works in JBPM3.2.GA. 
But when running in JBPM 3.2.1, it causes OutOfMemoryError. By testing, I found that if I change <jbpm:dataform columns="2"> to <jbpm:dataform>, it will work well in both JBPM3.2.GA and JBPM3.2.1. 
Sometimes it maybe works in JBPM3.2.1. But while adding more h:selectOneRadio,  I get the error.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >

<!-- the DOCTYPE means we are required to use html for a root element -->
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:c="http://java.sun.com/jstl/core"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:tf="http://jbpm.org/jsf/tf"
      xmlns:jbpm="http://jbpm.org/jsf">

  <ui:component>

    <jbpm:dataform columns="2">
  	
      <f:facet name="header">
        <h:outputText value="#{taskName}"/>
      </f:facet>
        
      <!-- TASKFORM ROWS -->
      <jbpm:datacell>
        <f:facet name="header">
            <h:outputText value="Sex"/>
        </f:facet>
        <h:selectOneRadio id="StudentSex" value="#{var['StudentSex']}"> 
			<f:selectItem itemLabel="Male" itemValue="Male"/>
	        <f:selectItem itemLabel="Female" itemValue="Female"/> 
	    </h:selectOneRadio>  
      </jbpm:datacell>

     <jbpm:datacell>
        <f:facet name="header">
            <h:outputText value="HasAS"/>
        </f:facet>
        <h:selectOneRadio id="HasAS" value="#{var['HasAS']}" >
      	    <f:selectItem itemLabel="Yes" itemValue="Yes"/>
	        <f:selectItem itemLabel="No" itemValue="No"/> 
	    </h:selectOneRadio>
      </jbpm:datacell>
    	    	    
      <jbpm:datacell>
        <f:facet name="header">
          <h:outputText value="Actions"/>
        </f:facet>
        <!-- TASKFORM BUTTONS -->
        <tf:saveButton value="Save"/>
        <tf:cancelButton value="Cancel"/>
        <tf:transitionButton value="Save and Close"/>
      </jbpm:datacell>
	    
    </jbpm:dataform>	
    
  </ui:component>

</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 lists.jboss.org  Mon Aug 13 13:18:01 2007
From: jira-events at lists.jboss.org (zhou guangzhao (JIRA))
Date: Mon, 13 Aug 2007 13:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1040) Improve
 jbpm:datacell with cross columns and rows feature
Message-ID: <16854121.1187025481280.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve jbpm:datacell with cross columns and rows feature
---------------------------------------------------------

                 Key: JBPM-1040
                 URL: http://jira.jboss.com/jira/browse/JBPM-1040
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Web Interface
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: zhou guangzhao
         Assigned To: Tom Baeyens


The tag <jbpm:dataform> now has attribute "columns" that makes the table has multi columns.
But each <jpbm:datacell> can only occupy one cell in the table generated automatically by dataform.
In some cases, user need a datacell to cross more columns or rows. 
So it is necessary to add the feature as title.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 14:13:13 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 13 Aug 2007 14:13:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4604) NamingContext does
 not take
 potential AutoDiscoveryAddress XML property overrides when sending
 discovery requests
Message-ID: <26585393.1187028793738.JavaMail.jira@cloud.prod.atl2.jboss.com>

NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests
-----------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4604
                 URL: http://jira.jboss.com/jira/browse/JBAS-4604
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Galder Zamarreno
         Assigned To: Brian Stansberry
            Priority: Minor


Bug in org.jnp.interfaces.NamingContext:

discoverServer(Hashtable) method

String group = DEFAULT_DISCOVERY_GROUP_ADDRESS;
...
String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP);
if (discoveryGroup != null)
group = discoveryGroup;
...
iaGroup = InetAddress.getByName(group);
....
if (trace)
log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port);

NamingContext code does not take in account possible system property overrides
coming from:

<attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>

AutoDiscoveryAddress used to send discovery messages is controlled via the the
default value, 230.0.0.4 or jnp.discoveryGroup property. 

So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, 
DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while 
NamingContext sends discovery requests to 230.0.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 lists.jboss.org  Mon Aug 13 14:20:19 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 13 Aug 2007 14:20:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4604) NamingContext does
 not take
 potential AutoDiscoveryAddress XML property overrides when sending
 discovery requests
In-Reply-To: <26585393.1187028793738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13773402.1187029219064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4604?page=all ]

Galder Zamarreno updated JBAS-4604:
-----------------------------------

    Workaround Description: 
There's 3 possible workarounds:

- remove XML override from AutoDiscoveryAddress, i.e:

<attribute name="AutoDiscoveryAddress">230.0.0.4</attribute>

- use a different XML override name so that jboss.partition.udpGroup use is liberated:

<attribute name="AutoDiscoveryAddress">${jboss.partition.autoDiscoveryGroup:230.0.0.4}</attribute>

- set AutoDiscoveryGroup via jnp.discoveryGroup system property, see:

http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingContextFactory

> NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4604
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4604
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Naming
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> Bug in org.jnp.interfaces.NamingContext:
> discoverServer(Hashtable) method
> String group = DEFAULT_DISCOVERY_GROUP_ADDRESS;
> ...
> String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP);
> if (discoveryGroup != null)
> group = discoveryGroup;
> ...
> iaGroup = InetAddress.getByName(group);
> ....
> if (trace)
> log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port);
> NamingContext code does not take in account possible system property overrides
> coming from:
> <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>
> AutoDiscoveryAddress used to send discovery messages is controlled via the the
> default value, 230.0.0.4 or jnp.discoveryGroup property. 
> So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, 
> DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while 
> NamingContext sends discovery requests to 230.0.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 lists.jboss.org  Mon Aug 13 14:22:01 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Mon, 13 Aug 2007 14:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4604) NamingContext does
 not take
 potential AutoDiscoveryAddress XML property overrides when sending
 discovery requests
In-Reply-To: <26585393.1187028793738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14761814.1187029321185.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4604?page=all ]

Galder Zamarreno updated JBAS-4604:
-----------------------------------

    Workaround Description: 
There're 3 possible workarounds:

1.- remove XML override from AutoDiscoveryAddress, i.e:
<attribute name="AutoDiscoveryAddress">230.0.0.4</attribute>

2.- use a different XML override name so that jboss.partition.udpGroup confusion is avoided, but 
without setting this property on startup! :
<attribute name="AutoDiscoveryAddress">${jboss.partition.autoDiscoveryGroup:230.0.0.4}</attribute>

3.- set AutoDiscoveryGroup via jnp.discoveryGroup system property, see:
http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingContextFactory

  was:
There's 3 possible workarounds:

- remove XML override from AutoDiscoveryAddress, i.e:

<attribute name="AutoDiscoveryAddress">230.0.0.4</attribute>

- use a different XML override name so that jboss.partition.udpGroup use is liberated:

<attribute name="AutoDiscoveryAddress">${jboss.partition.autoDiscoveryGroup:230.0.0.4}</attribute>

- set AutoDiscoveryGroup via jnp.discoveryGroup system property, see:

http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingContextFactory


> NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4604
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4604
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Naming
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> Bug in org.jnp.interfaces.NamingContext:
> discoverServer(Hashtable) method
> String group = DEFAULT_DISCOVERY_GROUP_ADDRESS;
> ...
> String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP);
> if (discoveryGroup != null)
> group = discoveryGroup;
> ...
> iaGroup = InetAddress.getByName(group);
> ....
> if (trace)
> log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port);
> NamingContext code does not take in account possible system property overrides
> coming from:
> <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>
> AutoDiscoveryAddress used to send discovery messages is controlled via the the
> default value, 230.0.0.4 or jnp.discoveryGroup property. 
> So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, 
> DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while 
> NamingContext sends discovery requests to 230.0.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 lists.jboss.org  Mon Aug 13 14:33:01 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Mon, 13 Aug 2007 14:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1079) Problem with "!="
 field constraint
Message-ID: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem with "!=" field constraint
----------------------------------

                 Key: JBRULES-1079
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Markus Reitz
         Assigned To: Mark Proctor


The following code illustrates the problem.

import org.drools.*;
import org.drools.compiler.*;
import org.drools.rule.Package;

import java.io.*;

public class DroolsTest {
  private RuleBase        rules;
  private StatefulSession memory;

  public DroolsTest(File file) throws Exception {
    rules =RuleBaseFactory.newRuleBase();
    memory=rules.newStatefulSession();
    
    rules.addPackage(loadPackage(file));
  }

  protected Package loadPackage(File file) throws IOException {
    FileInputStream stream=null;
    
    try {
      stream=new FileInputStream(file);
    
      return(loadPackage(stream));
    }
    finally {
      if (stream!=null)
        stream.close();
    }
  }

  protected Package loadPackage(InputStream stream) throws IOException {
    try {
      PackageBuilder builder=new PackageBuilder();

      builder.addPackageFromDrl(new InputStreamReader(stream));

      return(builder.getPackage());
    }
    catch(Exception ex) {
      throw new IOException();
    }
  }
  
  public StatefulSession getSession() {
    return(memory);
  }
  
  public static void main(String ... args) {
    try {
      DroolsTest test=new DroolsTest(new File(args[0]));
      
      SpecialString first42 =new SpecialString("42");
      SpecialString second42=new SpecialString("42");
      
      test.getSession().insert(new SpecialString("World"));
      test.getSession().insert(first42);
      test.getSession().insert(second42);
      
      System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
      System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
      
      System.out.println("Firing rules ...");
      
      test.getSession().fireAllRules();
    }
    catch (Exception ex) {
      ex.printStackTrace();
    }
  }
}

In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".

The class SpecialString uses the standard equals(...) and hashCode(...) implementation:

public class SpecialString {
  private String text;
  
  public SpecialString(String text) {
    this.text=text;
  }
  
  public String getText() {
    return(text);
  }
  
  @Override public String toString() {
    return(getText()+"["+super.toString()+"]");
  }
}

For the rule

  package test

  rule "A test"

    when
      x : SpecialString()
      y : SpecialString(this!=x)

    then
      System.out.println(x+"/"+y);
  end

The output is 

  Fact handle: [fid:2:2:42[SpecialString at fde8da]]
  Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
  Firing rules ...
  42[SpecialString at e4d6ef]/World[SpecialString at faa824]
  World[SpecialString at faa824]/42[SpecialString at e4d6ef]
  42[SpecialString at fde8da]/World[SpecialString at faa824]
  World[SpecialString at faa824]/42[SpecialString at fde8da]

I would expect that

  42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
  42[SpecialString at fde8da]/42[SpecialString at e4d6ef]

is also contained in the output, but this is not the 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 lists.jboss.org  Mon Aug 13 14:43:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Mon, 13 Aug 2007 14:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1325)
 ConsumerCacheInterceptor : should not use the cache just after login
In-Reply-To: <23196461.1174510488890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7457646.1187030581531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1325?page=comments#action_12371905 ] 
            
Antoine Herzog commented on JBPORTAL-1325:
------------------------------------------


This is not an issue..... (I did this jira in march when exploring things about cache... did not see the thing explained since by Julien).

Should be closed. 
(see comments yet above).

about checking : this was asked by Julien, but I think it was "just in case..."
I don't think it is usefull.

not yet using the cache with 2.6 (don't want to add this while starting some ajax stuff).... 

if I see something, I'll reopen this... but sure it won't be necessary.




> ConsumerCacheInterceptor : should not use the cache just after login
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1325
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1325
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: jbp 2.4.0
>            Reporter: Antoine Herzog
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Use case : 
>  - user come to the site. 
>  - Portlet show views for unchecked user. These views are put in the cache.
>  - user log in, let's say as admin
>  - the cached views still show the previous things, not taking into account the change of authorizations
>  - the user can't see the proper things
> usual needs :
>  - for I18n portals : change of locale when user log in. all the portlets must do the change, not depending on cache
>  - for admin or special roles features in the  portlet views
>  - for modes depending on roles (see forum post)
> In the default portal, there are no use of cache. so all these use cases are fullfiled.
> to reproduce the problem : 
>  - put some cache on the user portlet (great feature for prod), the user portlet window may not update after logging.
> resolution :
> in the ConsumerCacheInterceptor
> the CacheKey do not take into account the login state.
> see : public CacheKey(StateString navigationalState, WindowState windowState, Mode mode)
> so store the user name (or "unchecked") in the CacheEntry.
> put the parameter "userOfFragment" in the CacheKey.
> when retrieving the CacheEntry, compare the currentUser and the userOfFragment, and don't use the cache if different.
> just to see : can we have access to the logued user in this interceptor ? (that, i don't know)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:01:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Aug 2007 15:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24023551.1187031661423.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1079?page=all ]

Edson Tirelli reassigned JBRULES-1079:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Mon Aug 13 15:14:05 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 15:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1163) Add FQN versions
 of POJO Cache methods
Message-ID: <9866311.1187032445517.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add FQN versions of POJO Cache methods
--------------------------------------

                 Key: JBCACHE-1163
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1163
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Jason T. Greene
         Assigned To: Jason T. Greene
             Fix For: 2.1.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:46:01 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Mon, 13 Aug 2007 15:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14721459.1187034361544.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12371910 ] 
            
Antoine Herzog commented on JBPORTAL-1499:
------------------------------------------

I opened a design forum post :
http://jboss.org/index.html?module=bb&op=viewtopic&t=115999

and put a post on this one :
http://jboss.org/index.html?module=bb&op=viewtopic&t=112843

hope that something will get out.

For the time being : can't use the CMS full feature with security constraint on each docs, if you want a CMS repo datasource different from the Identity Hibernate datasource.

And can't say for a prod environnement : let's mix the tables of CMS and Identity in the same database...
The prod admin will manage to backup, move from dev to prod... checking each time what table to take, what not to touch etc...





> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:55:01 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 13 Aug 2007 15:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
Message-ID: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>

JSP compiler won't compile JDK 1.5 source
-----------------------------------------

                 Key: JBAS-4605
                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Stan Silvert
         Assigned To: Stan Silvert


>From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 15:59:11 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Mon, 13 Aug 2007 15:59:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1499) CMSAdminPortlet
 should use Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12683346.1187035151558.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=all ]

Sohil Shah updated JBPORTAL-1499:
---------------------------------

    JBoss Forum Reference: http://jboss.org/index.html?module=bb&op=viewtopic&t=115999

> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 16:18:01 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Mon, 13 Aug 2007 16:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32216310.1187036281931.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12371916 ] 
            
Sohil Shah commented on JBPORTAL-1499:
--------------------------------------

Based on the discussion,

looks like what we need to do is fix the small bug I mentioned in my earlier comments. With this the HSQL based queries will be used by the Security Engine as a performance optimization, only for the DB based Identity Module that ships with the
Portal out-of-the-box. This module stores data inside the Portal database.

For other implementations of the Identity API which stores data in different stores like LDAP, another database etc, the CMS Security Engine will fall back to use the generic Identity API to gets its information.

In this case however. all performance optimizations will be resposibility of the Identity Module Implementation itself.

> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 17:18:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Aug 2007 17:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
In-Reply-To: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7375317.1187039881398.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3720?page=all ]

Brian Stansberry reopened JBAS-3720:
------------------------------------

             
Thanks, Hany. :)  I'm reopening pending getting the test to work; will close once it passes.

> 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: Web (Tomcat) service, Clustering
>            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 lists.jboss.org  Mon Aug 13 17:20:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Aug 2007 17:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
In-Reply-To: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10489867.1187040001072.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3720?page=all ]

Brian Stansberry updated JBAS-3720:
-----------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                       (was: JBossAS-5.0.0.CR1)

> 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: Web (Tomcat) service, Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> 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 lists.jboss.org  Mon Aug 13 17:22:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 13 Aug 2007 17:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1325)
 ConsumerCacheInterceptor : should not use the cache just after login
In-Reply-To: <23196461.1174510488890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6688364.1187040121808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1325?page=all ]

Thomas Heute resolved JBPORTAL-1325.
------------------------------------

    Resolution: Won't Fix
      Assignee: Thomas Heute  (was: Julien Viet)

I mark it resolved as "won't fix" then, thanks.

> ConsumerCacheInterceptor : should not use the cache just after login
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1325
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1325
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: jbp 2.4.0
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Use case : 
>  - user come to the site. 
>  - Portlet show views for unchecked user. These views are put in the cache.
>  - user log in, let's say as admin
>  - the cached views still show the previous things, not taking into account the change of authorizations
>  - the user can't see the proper things
> usual needs :
>  - for I18n portals : change of locale when user log in. all the portlets must do the change, not depending on cache
>  - for admin or special roles features in the  portlet views
>  - for modes depending on roles (see forum post)
> In the default portal, there are no use of cache. so all these use cases are fullfiled.
> to reproduce the problem : 
>  - put some cache on the user portlet (great feature for prod), the user portlet window may not update after logging.
> resolution :
> in the ConsumerCacheInterceptor
> the CacheKey do not take into account the login state.
> see : public CacheKey(StateString navigationalState, WindowState windowState, Mode mode)
> so store the user name (or "unchecked") in the CacheEntry.
> put the parameter "userOfFragment" in the CacheKey.
> when retrieving the CacheEntry, compare the currentUser and the userOfFragment, and don't use the cache if different.
> just to see : can we have access to the logued user in this interceptor ? (that, i don't know)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 17:24:01 2007
From: jira-events at lists.jboss.org (Micah Modell (JIRA))
Date: Mon, 13 Aug 2007 17:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-144) Renaming Task and
 Generating Form yields incorrect forms.xml
Message-ID: <28233236.1187040241261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Renaming Task and Generating Form yields incorrect forms.xml
------------------------------------------------------------

                 Key: GPD-144
                 URL: http://jira.jboss.com/jira/browse/GPD-144
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM JPDL Designer 3.0.13
         Environment: RHEL 5
Eclipse 3.3
Sun Java 1.5_12
            Reporter: Micah Modell
         Assigned To: Koen Aers


If you create a new task on a TaskNode, rename it in the "General" tab and then use "Generate Form..." in the "Advanced" tab, the forms.xml entry references the original task name rather than the updated one.  This causes the jBPM admin console to be unable to find the task form.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 17:58:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 13 Aug 2007 17:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-383) Complete Retro
	Mavenization
In-Reply-To: <30433964.1181834471757.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25589315.1187042281312.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-383?page=all ]

Paul Gier reassigned JBBUILD-383:
---------------------------------

    Assignee: Paul Gier

> Complete Retro Mavenization
> ---------------------------
>
>                 Key: JBBUILD-383
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-383
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: JBossRetro-1.1.3.GA
>
>
> The mavenization can be completed when the next surefire plugin is released.
> Also there needs to be a way to configure the manifest file for the runtime jar.
> Look into breaking retro into three modules: weaver, retro-runtime, and maven-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 lists.jboss.org  Mon Aug 13 18:42:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 18:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-518) Investigate use a
 new replication schema for PojoCache
Message-ID: <16695928.1187044921291.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ]

Jason T. Greene resolved JBCACHE-518.
-------------------------------------

    Resolution: Rejected

> Investigate use a new replication schema for PojoCache
> ------------------------------------------------------
>
>                 Key: JBCACHE-518
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-518
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>             Fix For: PojoCache 2.2.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive.
> The other issue is what to do with automicity during putObject and removeObject?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 18:46:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 18:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-518) Investigate use a
 new replication schema for PojoCache
Message-ID: <12821170.1187045161225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ]

Jason T. Greene updated JBCACHE-518:
------------------------------------

    Fix Version/s:     (was: PojoCache 2.2.0)

> Investigate use a new replication schema for PojoCache
> ------------------------------------------------------
>
>                 Key: JBCACHE-518
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-518
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive.
> The other issue is what to do with automicity during putObject and removeObject?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:06:17 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-288) Enable garbage
 collection for Pojo under cache management
Message-ID: <6546855.1187046377269.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-288?page=all ]

Jason T. Greene closed JBCACHE-288.
-----------------------------------

    Fix Version/s:     (was: PojoCache)
       Resolution: Rejected

> Enable garbage collection for Pojo under cache management
> ---------------------------------------------------------
>
>                 Key: JBCACHE-288
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-288
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Currently, once the pojo is put into cache, it won't get gced unless user specifically issues removeObject. There is eviction policy. However, it is coupled with cache loader so the object is still around for a specific time span. We should come up with a way to gc these pojos properly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:06:17 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Mon, 13 Aug 2007 19:06:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1039) OutOfMemoryError
 While using multi h:selectOneRaido in dataform with multy columns
In-Reply-To: <21038826.1187024521208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21655046.1187046377462.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1039?page=all ]

Ronald van Kuijk updated JBPM-1039:
-----------------------------------

    Priority: Minor  (was: Major)

> OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns
> ----------------------------------------------------------------------------------
>
>                 Key: JBPM-1039
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1039
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1     Tomcat 6.0.14
>            Reporter: zhou guangzhao
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> The following taskform code works in JBPM3.2.GA. 
> But when running in JBPM 3.2.1, it causes OutOfMemoryError. By testing, I found that if I change <jbpm:dataform columns="2"> to <jbpm:dataform>, it will work well in both JBPM3.2.GA and JBPM3.2.1. 
> Sometimes it maybe works in JBPM3.2.1. But while adding more h:selectOneRadio,  I get the error.
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
> <!-- the DOCTYPE means we are required to use html for a root element -->
> <html xmlns="http://www.w3.org/1999/xhtml"
>       xmlns:ui="http://java.sun.com/jsf/facelets"
>       xmlns:c="http://java.sun.com/jstl/core"
>       xmlns:h="http://java.sun.com/jsf/html"
>       xmlns:f="http://java.sun.com/jsf/core"
>       xmlns:tf="http://jbpm.org/jsf/tf"
>       xmlns:jbpm="http://jbpm.org/jsf">
>   <ui:component>
>     <jbpm:dataform columns="2">
>   	
>       <f:facet name="header">
>         <h:outputText value="#{taskName}"/>
>       </f:facet>
>         
>       <!-- TASKFORM ROWS -->
>       <jbpm:datacell>
>         <f:facet name="header">
>             <h:outputText value="Sex"/>
>         </f:facet>
>         <h:selectOneRadio id="StudentSex" value="#{var['StudentSex']}"> 
> 			<f:selectItem itemLabel="Male" itemValue="Male"/>
> 	        <f:selectItem itemLabel="Female" itemValue="Female"/> 
> 	    </h:selectOneRadio>  
>       </jbpm:datacell>
>      <jbpm:datacell>
>         <f:facet name="header">
>             <h:outputText value="HasAS"/>
>         </f:facet>
>         <h:selectOneRadio id="HasAS" value="#{var['HasAS']}" >
>       	    <f:selectItem itemLabel="Yes" itemValue="Yes"/>
> 	        <f:selectItem itemLabel="No" itemValue="No"/> 
> 	    </h:selectOneRadio>
>       </jbpm:datacell>
>     	    	    
>       <jbpm:datacell>
>         <f:facet name="header">
>           <h:outputText value="Actions"/>
>         </f:facet>
>         <!-- TASKFORM BUTTONS -->
>         <tf:saveButton value="Save"/>
>         <tf:cancelButton value="Cancel"/>
>         <tf:transitionButton value="Save and Close"/>
>       </jbpm:datacell>
> 	    
>     </jbpm:dataform>	
>     
>   </ui:component>
> </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 lists.jboss.org  Mon Aug 13 19:10:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-281) PojoCahce
 initialize "aspectized" pojos when first retrieved
Message-ID: <4305884.1187046601243.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-281?page=all ]

Jason T. Greene resolved JBCACHE-281.
-------------------------------------

    Fix Version/s:     (was: PojoCache 2.1.0)
       Resolution: Out of Date

This is already done in detach()

> PojoCahce initialize "aspectized" pojos when first retrieved
> ------------------------------------------------------------
>
>                 Key: JBCACHE-281
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-281
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, when we do getObject for the first time, we don't initialize the "aspectized" pojo after a get/set is requested. As a result, some of the fields will be un-initialized untill after they are accessed.
> We need to provide an option to actively initialize the pojos.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:10:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-71) Resizing cache at
	runtime
Message-ID: <26057530.1187046601471.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-71?page=all ]

Jason T. Greene closed JBCACHE-71.
----------------------------------

    Fix Version/s:     (was: 3.0.0)
       Resolution: Out of Date

There is a new region design.

> Resizing cache at runtime
> -------------------------
>
>                 Key: JBCACHE-71
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-71
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> With the dynamic runtime configuration of eviction policy, we should be able to resize the cache at runtime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 19:12:02 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Mon, 13 Aug 2007 19:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-318) CacheLoader
 persistent item should have an age limit
Message-ID: <3208022.1187046722414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-318?page=all ]

Jason T. Greene reassigned JBCACHE-318:
---------------------------------------

    Assignee: Manik Surtani  (was: Jason T. Greene)

> CacheLoader persistent item should have an age limit
> ----------------------------------------------------
>
>                 Key: JBCACHE-318
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-318
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Currently items that are persisted has no notion of age out. So let's say it is fairly common in SFSB to have the state not live more than 2 weeks in the store, for example. The other usage is when the cache crashed and the persistent store won't get cleaned up even when the items are orphaned.
> Bela refused to put this functionality in the cache loader layer. So Manik's idea is to wrap around the object in the CacheStoreInterceptor with an additional timestamp. This way an offline thread can come in and clean them.
> We can also check how does the current SFSB does 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 lists.jboss.org  Mon Aug 13 19:14:16 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Mon, 13 Aug 2007 19:14:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1040) Improve
 jbpm:datacell with cross columns and rows feature
In-Reply-To: <16854121.1187025481280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25681034.1187046856829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1040?page=all ]

Ronald van Kuijk updated JBPM-1040:
-----------------------------------

    Priority: Optional  (was: Major)

like the colspan and rowspan in html tables?

> Improve jbpm:datacell with cross columns and rows feature
> ---------------------------------------------------------
>
>                 Key: JBPM-1040
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1040
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Web Interface
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: zhou guangzhao
>         Assigned To: Tom Baeyens
>            Priority: Optional
>
> The tag <jbpm:dataform> now has attribute "columns" that makes the table has multi columns.
> But each <jpbm:datacell> can only occupy one cell in the table generated automatically by dataform.
> In some cases, user need a datacell to cross more columns or rows. 
> So it is necessary to add the feature as title.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 20:05:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 13 Aug 2007 20:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1080) Modify (var)
 added to Eclipse code completion for mvel
Message-ID: <19252810.1187049901307.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify (var) added to Eclipse code completion for mvel
------------------------------------------------------

                 Key: JBRULES-1080
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1080
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 4.0.1
            Reporter: Philippe Ombredanne
         Assigned To: Philippe Ombredanne
            Priority: Minor
         Attachments: mvel.png

Reported by Mark: 
I've found a weird one with context assist, some how its adding "modify ( var )" to the list of context completions, but it only does that if you've already added the line to the consequence. See modify( game ).



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 20:05:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 13 Aug 2007 20:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1080) Modify (var)
 added to Eclipse code completion for mvel
In-Reply-To: <19252810.1187049901307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18971720.1187049901456.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1080?page=all ]

Philippe Ombredanne updated JBRULES-1080:
-----------------------------------------

    Attachment: mvel.png

> Modify (var) added to Eclipse code completion for mvel
> ------------------------------------------------------
>
>                 Key: JBRULES-1080
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1080
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Philippe Ombredanne
>            Priority: Minor
>         Attachments: mvel.png
>
>
> Reported by Mark: 
> I've found a weird one with context assist, some how its adding "modify ( var )" to the list of context completions, but it only does that if you've already added the line to the consequence. See modify( game ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 20:22:01 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Mon, 13 Aug 2007 20:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
Message-ID: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>

Repository exception occurs duing opening, creation of the rules
----------------------------------------------------------------

                 Key: JBRULES-1081
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
         Environment: Standard version of BRMS
            Reporter: Joe Son
         Assigned To: Mark Proctor


I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:

javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent

It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 

Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 21:11:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Mon, 13 Aug 2007 21:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-382) Remove Complex
 Advice Signatures from Classic Mode
In-Reply-To: <23885199.1176740459311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14482314.1187053861268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-382?page=comments#action_12371942 ] 
            
Stale Pedersen commented on JBAOP-382:
--------------------------------------

args tests are moved and method params are now required to implement org.jboss.aop.joinpoint.Invocation

> Remove Complex Advice Signatures from Classic Mode
> --------------------------------------------------
>
>                 Key: JBAOP-382
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-382
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.beta
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We need to update PerVMAdvice class, to remove the possibility of advices that receive joinpoint arguments (currently, the matching of parameters is not completely functional).
> We will leave the possibility of receiving joinpoint arguments as parameters to the annotated-parameters signature.
> This task also includes moving arg tests to beforeafterArgs package.
> PS: documentation is already stating that only annotated-parameters advice signatures can feature joinpoint arguments as parameters. No need to update documentation here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 22:43:01 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 13 Aug 2007 22:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
In-Reply-To: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11236972.1187059381078.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4605?page=all ]

Stan Silvert updated JBAS-4605:
-------------------------------

    Component/s: Web (Tomcat) service

> JSP compiler won't compile JDK 1.5 source
> -----------------------------------------
>
>                 Key: JBAS-4605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>
> From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 13 22:45:25 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 13 Aug 2007 22:45:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
In-Reply-To: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12831253.1187059525861.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4605?page=comments#action_12371946 ] 
            
Stan Silvert commented on JBAS-4605:
------------------------------------

This is already fixed in JBoss 5.  We can just add compilerSourceVM to conf/web.xml in the 4.2 branch.

> JSP compiler won't compile JDK 1.5 source
> -----------------------------------------
>
>                 Key: JBAS-4605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>
> From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:03:11 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:03:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-165) Option to exclude
 fields from "aspectized" in aop
Message-ID: <6852910.1187064191225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-165?page=all ]

Jason T. Greene closed JBCACHE-165.
-----------------------------------

    Fix Version/s:     (was: 2.1.0.GA)
       Resolution: Out of Date

See @Transient

> Option to exclude fields from "aspectized" in aop
> -------------------------------------------------
>
>                 Key: JBCACHE-165
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-165
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>            Priority: Minor
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> There may a time when a user wants certain fields in the POJO to be excluded from TreeCacheAop management. Currently, if a field is declared "transient", we have that effect. But still we may want to have a flag for this specific purpose.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:05:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-663) Setup system
 property for Id string separator
Message-ID: <30847069.1187064301190.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-663?page=all ]

Jason T. Greene resolved JBCACHE-663.
-------------------------------------

    Fix Version/s:     (was: PojoCache)
       Resolution: Rejected

> Setup system property for Id string separator
> ---------------------------------------------
>
>                 Key: JBCACHE-663
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-663
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> In 2.0 release, we will use id String instead the old fqn. We will also use a system property called jbosscache.separator to allow user to use a different character as the separator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:05:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-663) Setup system
 property for Id string separator
Message-ID: <5810358.1187064301408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-663?page=all ]

Jason T. Greene closed JBCACHE-663.
-----------------------------------


> Setup system property for Id string separator
> ---------------------------------------------
>
>                 Key: JBCACHE-663
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-663
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> In 2.0 release, we will use id String instead the old fqn. We will also use a system property called jbosscache.separator to allow user to use a different character as the separator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 00:09:01 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-771) PojoCache to have
 events reacting to transactional context
In-Reply-To: <5459146.1158485139891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28298462.1187064541480.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-771?page=all ]

Jason T. Greene resolved JBCACHE-771.
-------------------------------------

    Fix Version/s: 2.0.0.GA
                       (was: 2.1.0.GA)
       Resolution: Done

This was implemented in the notification API of 2.0.0.GA

> 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: Jason T. Greene
>             Fix For: 2.0.0.GA
>
>
> 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 lists.jboss.org  Tue Aug 14 00:14:10 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Tue, 14 Aug 2007 00:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-925) PojoCache to
 re-try if UpgradeException occur
In-Reply-To: <18289277.1167962066834.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16968110.1187064850838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-925?page=all ]

Jason T. Greene resolved JBCACHE-925.
-------------------------------------

    Fix Version/s:     (was: 2.1.0.GA)
       Resolution: Out of Date

This will no longer be necessary with MVCC

> PojoCache to re-try if UpgradeException occur
> ---------------------------------------------
>
>                 Key: JBCACHE-925
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-925
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Jason T. Greene
>
> Currently, PojoCache attach & detach is prone to encoutner UpgradeException on __JBossInternal__ node. This is becuase of the flat space approach that we use such that all the POJO are stored there. As a result, UpgradeException can happen and we should catch it and re-try 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 lists.jboss.org  Tue Aug 14 01:58:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 01:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1052) When Inserting
 a fact cannot set a String field
In-Reply-To: <1292464.1185911829398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9013397.1187071081145.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1052?page=comments#action_12371956 ] 
            
Michael Neale commented on JBRULES-1052:
----------------------------------------

there is a test for this in the model stuff (so I presume it is infering the type from the model correctly).
Need to confirm that this is a bug in the eclipse tool not the web as well. 

> When Inserting a fact cannot set a String field
> -----------------------------------------------
>
>                 Key: JBRULES-1052
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1052
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> A String field only let me put in numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 02:00:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 02:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-923) change
 BRDRLPersistence to emit packages that use MVEL
In-Reply-To: <4742060.1181727136865.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12097230.1187071201183.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-923?page=all ]

Michael Neale closed JBRULES-923.
---------------------------------

    Resolution: Done
      Assignee: Michael Neale  (was: Edson Tirelli)

> change BRDRLPersistence to emit packages that use MVEL
> ------------------------------------------------------
>
>                 Key: JBRULES-923
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-923
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions: 4.0.0.MR2
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> Mark thinks it may be a good idea to generate to MVEL instead of Java - what say you? 
> I think this simply means adding an attribute of "dialect 'mvel' " to the top of the package, and testing.
> Its possible to generate the RHS using the accessors like:
> foo.bar = "value" 
> for assignment - not sure if that is better or 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 lists.jboss.org  Tue Aug 14 02:00:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 02:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5623813.1187071201574.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=all ]

Michael Neale reassigned JBRULES-1081:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

Fer - any clues on how to reproduce? if you can't repo with the info given, close it off. 

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 02:41:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 14 Aug 2007 02:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5802337.1187073661617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12371960 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

waiting for input form Barry...

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Tue Aug 14 03:28:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
Message-ID: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invoke remote EJB3 from JVM 1.4 client
--------------------------------------

                 Key: EJBTHREE-1029
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
             Project: EJB 3.0
          Issue Type: Patch
         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
Client : JDK 1.4.2
            Reporter: Boris Maras


Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.

So I used jbossretro to convert this jar in jdk 1.4 compatible format.
That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)

In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
- the client jar for your EJBs
- the generated jboss-ejb3-client14.jar
- jbossretro-rt.jar
- jboss-backport-concurrent.jar
- javassist.jar

I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.

I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.

I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
- uncompress the file jboss-ejb3.jar
- delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
- run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
- recompress the jar

This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 03:31:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
In-Reply-To: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28861379.1187076661155.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1029?page=all ]

Boris Maras updated EJBTHREE-1029:
----------------------------------

    Attachment: patch build.xml ejb3-client1.4.txt

Path for the current version of file ejb3/build.xml
It generates a new file : jboss-ejb3-client14.jar that can be used to call remote EJB3s from a JVM 1.4 client

> Invoke remote EJB3 from JVM 1.4 client
> --------------------------------------
>
>                 Key: EJBTHREE-1029
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
>             Project: EJB 3.0
>          Issue Type: Patch
>         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
> Client : JDK 1.4.2
>            Reporter: Boris Maras
>         Attachments: patch build.xml ejb3-client1.4.txt
>
>
> Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.
> So I used jbossretro to convert this jar in jdk 1.4 compatible format.
> That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)
> In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
> - the client jar for your EJBs
> - the generated jboss-ejb3-client14.jar
> - jbossretro-rt.jar
> - jboss-backport-concurrent.jar
> - javassist.jar
> I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.
> I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.
> I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
> - uncompress the file jboss-ejb3.jar
> - delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
> - run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
> - recompress the jar
> This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 03:34:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
In-Reply-To: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11171459.1187076841078.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1029?page=all ]

Boris Maras updated EJBTHREE-1029:
----------------------------------

    Attachment: build-client1.4convert.xml

This ant script uses an existing jboss-ejb3.jar to generate a jboss-ejb3-client14.jar that can be used to call remote EJB3s from a jvm 1.4 client.
I created this ant script to be able to generate this jar on older versions of JBoss & EJB3.
I tested it on JBoss 4.0.3SP1 and EJB3 RC6

> Invoke remote EJB3 from JVM 1.4 client
> --------------------------------------
>
>                 Key: EJBTHREE-1029
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
>             Project: EJB 3.0
>          Issue Type: Patch
>         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
> Client : JDK 1.4.2
>            Reporter: Boris Maras
>         Attachments: build-client1.4convert.xml, patch build.xml ejb3-client1.4.txt
>
>
> Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.
> So I used jbossretro to convert this jar in jdk 1.4 compatible format.
> That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)
> In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
> - the client jar for your EJBs
> - the generated jboss-ejb3-client14.jar
> - jbossretro-rt.jar
> - jboss-backport-concurrent.jar
> - javassist.jar
> I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.
> I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.
> I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
> - uncompress the file jboss-ejb3.jar
> - delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
> - run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
> - recompress the jar
> This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 03:36:01 2007
From: jira-events at lists.jboss.org (Boris Maras (JIRA))
Date: Tue, 14 Aug 2007 03:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1029) Invoke remote
 EJB3 from JVM 1.4 client
In-Reply-To: <18937523.1187076481252.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10747830.1187076961065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1029?page=all ]

Boris Maras updated EJBTHREE-1029:
----------------------------------

    Attachment: jboss-ejb3-client14.jar

This jar should work with JBoss 4.0.3SP1 and EJB3 RC6. It probably doesn't work for other versions of JBoss & EJB3.
It has been generated with the attached ant script.

> Invoke remote EJB3 from JVM 1.4 client
> --------------------------------------
>
>                 Key: EJBTHREE-1029
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1029
>             Project: EJB 3.0
>          Issue Type: Patch
>         Environment: Server : JDK 1.5.0_10, JBoss 4.0.3SP1 + EJB3 jars (RC6), EJB 3 Session Stateless
> Client : JDK 1.4.2
>            Reporter: Boris Maras
>         Attachments: build-client1.4convert.xml, jboss-ejb3-client14.jar, patch build.xml ejb3-client1.4.txt
>
>
> Natively, you cannot use a JVM 1.4 client to call JBoss EJB3. This is because the jboss-ejb3.jar is compiled with JDK 1.5 : using it in a 1.4 JVM gives errors on major/minor version.
> So I used jbossretro to convert this jar in jdk 1.4 compatible format.
> That gave me a jar that works in my jvm 1.4 client (see attached file, to be used with JBoss 4.0.3SP1 + EJB3 RC6)
> In order to use it, you also need to create a client jar for your EJBs, compiled with a 1.4 target. At compile time, you'll probably need to remove some annotations (@Local, @Remote etc). Thus, you need on the client side :
> - the client jar for your EJBs
> - the generated jboss-ejb3-client14.jar
> - jbossretro-rt.jar
> - jboss-backport-concurrent.jar
> - javassist.jar
> I tested that on JBoss 4.0.3SP1+EJB3 RC6, with Session Stateless Beans only.
> I attach a patch for the current version of ejb3/build.xml, that generates the jboss-ejb3-client14.jar for the current version. I could not test this version, because I only use JBoss 4.0.3SP1, that doesn't support it.
> I also attach the jboss-ejb3-client14.jar that works with EJB3 RC6 and JBoss 4.0.3SP1. I generated it with another ant script (also attached), that does this :
> - uncompress the file jboss-ejb3.jar
> - delete all files that are not included in jboss-ejb3-client.jar (based on the list of current ejb3/build.xml)
> - run jbossretro on the classes, using the jboss 4.0.3SP1 libraries on the classpath
> - recompress the jar
> This ant script should probably let you convert the jar of other versions of JBoss & EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:05:16 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Tue, 14 Aug 2007 04:05:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-145) bend points not
	displayed
Message-ID: <30921152.1187078716931.JavaMail.jira@cloud.prod.atl2.jboss.com>

bend points not displayed
-------------------------

                 Key: GPD-145
                 URL: http://jira.jboss.com/jira/browse/GPD-145
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
            Reporter: David Good
         Assigned To: Koen Aers


When opening an existing design in beta2 all existing bendpoints are ignored.  The bendpoints can be restored manually and saved,  but are not displayed when the design is re-opened.  If the design is opened in beta1, bendpoints are displayed as expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:12:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 04:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-145) bend points not
	displayed
In-Reply-To: <30921152.1187078716931.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3625367.1187079121071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-145?page=all ]

Koen Aers closed GPD-145.
-------------------------

    Resolution: Duplicate Issue

This is a duplicate of GPD-135 wich was fixed for the the 3.1.0.CR1 release.

> bend points not displayed
> -------------------------
>
>                 Key: GPD-145
>                 URL: http://jira.jboss.com/jira/browse/GPD-145
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
>            Reporter: David Good
>         Assigned To: Koen Aers
>
> When opening an existing design in beta2 all existing bendpoints are ignored.  The bendpoints can be restored manually and saved,  but are not displayed when the design is re-opened.  If the design is opened in beta1, bendpoints are displayed as expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:19:25 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 04:19:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-144) Renaming Task and
 Generating Form yields incorrect forms.xml
In-Reply-To: <28233236.1187040241261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19906397.1187079565590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-144?page=all ]

Koen Aers closed GPD-144.
-------------------------

    Resolution: Won't Fix

This bug can be worked around easily, I guess by first saving the name and then reopening the properties dialog. We will focus on fixing bugs on the 3.1.x branch and not on the 3.0.x branch as we don't have the resources and 3.1.x provides already a lot more functionality. 

> Renaming Task and Generating Form yields incorrect forms.xml
> ------------------------------------------------------------
>
>                 Key: GPD-144
>                 URL: http://jira.jboss.com/jira/browse/GPD-144
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM JPDL Designer 3.0.13
>         Environment: RHEL 5
> Eclipse 3.3
> Sun Java 1.5_12
>            Reporter: Micah Modell
>         Assigned To: Koen Aers
>
> If you create a new task on a TaskNode, rename it in the "General" tab and then use "Generate Form..." in the "Advanced" tab, the forms.xml entry references the original task name rather than the updated one.  This causes the jBPM admin console to be unable to find the task form.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 04:36:01 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Tue, 14 Aug 2007 04:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30182901.1187080561177.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12371975 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

sure I will do, I am in meetings with one of our clients today, so this will probably be done tomorrow,

cheers

Ross

> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Tue Aug 14 04:54:01 2007
From: jira-events at lists.jboss.org (Barry Knapp (JIRA))
Date: Tue, 14 Aug 2007 04:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13693642.1187081641605.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12371979 ] 
            
Barry Knapp commented on JBRULES-1020:
--------------------------------------

A filter for rules so the output is only the items that match would work well.

Here is a use case using 5 attributes of a rule:
1. Effective Date
2. Expiration Date
3. Test Effective Date
4. Test Expiration Date
5. Tested Status


There are 2 deployment types, one for deploying to test servers and one for production servers:

1.  Test Server : Users will create snapshot of rules to deploy to the Test Servers containing rules that meet the following criteria:

Test Effective Date >= Today
Test Expiration Date <= Today


2.  Production Server: Users will create snapshot of rules to deploy to the Production Servers containing rules that meet the following criteria:

Effective Date >=Today
Expiration Date >= Today
Tested Status = true



Justification: 
1.  Users must test new rules in the test servers, prior to moving them to production.
2.  Users must test the absence of rules in the test servers, prior to removing them from production.
3.  Users must test the replacement of rules in the test servers, such as when the logic of a rule is found to be incorrect and it is replaced by a new rule.


In my implementation I am always using the most recent version, so there is not much need for the historical search to meet this requirement.

___________________________________



> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Tue Aug 14 04:59:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 14 Aug 2007 04:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-573) Draw blocks with
 FLUSH (join & state transfer)
Message-ID: <10915282.1187081941172.JavaMail.jira@cloud.prod.atl2.jboss.com>

Draw blocks with FLUSH (join & state transfer)
----------------------------------------------

                 Key: JGRP-573
                 URL: http://jira.jboss.com/jira/browse/JGRP-573
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6
            Reporter: Bela Ban
         Assigned To: Vladimir Blagojevic
             Fix For: 2.6


To reproduce:
#1 Get the latest from CVS head
#2 Start 1 Draw: java org.jgroups.demos.Draw -props ./flush-udp.xml -state -use_blocking

- The flush-udp.xml config was copied from JGroups/conf and not modified
- use_blocking sets the Channel to use blocking

#3 Draw some points into Draw 
#4 Start a second instance of Draw
RESULT: the second instance does join correctly and also transfers the state correctly, but it hangs on FLUSH:

[linux]/home/bela$ draw -props ./flush-udp.xml -state -use_blocking

-------------------------------------------------------
GMS: address is 192.168.0.5:33755
-------------------------------------------------------
--  received BlockEvent
** View=[192.168.0.5:33754|1] [192.168.0.5:33754, 192.168.0.5:33755]
read state: 139 entries
-- received UnblockEvent
0 [WARN] [main] JChannel.connect(): 192.168.0.5:33755 waiting on UNBLOCK after connect timed 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 lists.jboss.org  Tue Aug 14 05:01:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 14 Aug 2007 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-573) Draw blocks with
 FLUSH (join & state transfer)
In-Reply-To: <10915282.1187081941172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30470815.1187082061168.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-573?page=comments#action_12371980 ] 
            
Bela Ban commented on JGRP-573:
-------------------------------

This works if I don't use join&state, but call connect() and getState() in separate steps

> Draw blocks with FLUSH (join & state transfer)
> ----------------------------------------------
>
>                 Key: JGRP-573
>                 URL: http://jira.jboss.com/jira/browse/JGRP-573
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> To reproduce:
> #1 Get the latest from CVS head
> #2 Start 1 Draw: java org.jgroups.demos.Draw -props ./flush-udp.xml -state -use_blocking
> - The flush-udp.xml config was copied from JGroups/conf and not modified
> - use_blocking sets the Channel to use blocking
> #3 Draw some points into Draw 
> #4 Start a second instance of Draw
> RESULT: the second instance does join correctly and also transfers the state correctly, but it hangs on FLUSH:
> [linux]/home/bela$ draw -props ./flush-udp.xml -state -use_blocking
> -------------------------------------------------------
> GMS: address is 192.168.0.5:33755
> -------------------------------------------------------
> --  received BlockEvent
> ** View=[192.168.0.5:33754|1] [192.168.0.5:33754, 192.168.0.5:33755]
> read state: 139 entries
> -- received UnblockEvent
> 0 [WARN] [main] JChannel.connect(): 192.168.0.5:33755 waiting on UNBLOCK after connect timed 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 lists.jboss.org  Tue Aug 14 06:35:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 06:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25270039.1187087701140.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1027?page=comments#action_12371982 ] 
            
Tim Fox commented on JBMESSAGING-1027:
--------------------------------------

There are two distinct major issues with the current client side failover info updating code:

1)
I download a connection factory
The network topology changes
I create a connection
The network topology is never updated on the client side

2)
I download a connection factory
The network topology changes such that none of the original nodes exist any more
I attempt to create a connection - this fails since none of the original nodes exist any more

The fundamental issue in the current implementation is that the updates are done on the *connection* - they should be done on the connection factory.

We need updates to happen even if there are no connections!!

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 07:01:13 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Tue, 14 Aug 2007 07:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7023201.1187089273411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen resolved JBAOP-449.
----------------------------------

    Resolution: Done

fixed by adding
<aoppaths>
  <aoppath></aoppath>
</aoppaths>
this makes it more multiplattform friendly..

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 07:01:13 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Tue, 14 Aug 2007 07:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-449) maven-jbossaop-plugin
 cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2199636.1187089273572.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen closed JBAOP-449.
--------------------------------


> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 07:08:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Aug 2007 07:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-450) AOP/MC Proxies do
 not include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21021140.1187089681366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-450?page=all ]

Kabir Khan updated JBAOP-450:
-----------------------------

    Attachment: test.zip

THe attached files illustrate the problem. Using javassist the annotations are there, but they are not picked up using the reflection api

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.beta
>
>         Attachments: test.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 lists.jboss.org  Tue Aug 14 07:14:01 2007
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Tue, 14 Aug 2007 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4606) Hypersonic server
 mode TCP socket problem
Message-ID: <5093937.1187090041430.JavaMail.jira@cloud.prod.atl2.jboss.com>

Hypersonic server mode TCP socket problem
-----------------------------------------

                 Key: JBAS-4606
                 URL: http://jira.jboss.com/jira/browse/JBAS-4606
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.2.0.GA
         Environment: Sun JVM, x86_64&i686, RHEL5, JBossAS conf. "default", running as service jbossas.
            Reporter: Martin Vecera
         Assigned To: Dimitris Andreadis


I wanted to deploy Duke's bank J2EE example. This requires HSQLDB in server mode. The server/deploy/hsqldb-ds.xml is well prepared for switching HSQLDB to server mode, so I did it. This XML file uses ${jboss.bind.address} property to determine HSQLDB binding address.

I was running JBossAS with 'service jbossas start'. In /etc/sysconfig/jbossas I had JBOSS_IP=127.0.0.1.
I got the following error:
2007-08-14 13:27:30,715 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)
        at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:179)
        at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
        at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
        at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
        at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
        at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
        at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
        at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
        at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
        at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
        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 org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        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 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 $Proxy42.start(Unknown Source)
        at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
        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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:508)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.sql.SQLException: socket creation error
        at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
        at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
        at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
        at org.hsqldb.jdbcDriver.connect(Unknown Source)
        at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
        ... 122 more

When I replaced the {$jboss.bind.address} (both occurences in hsqldb-ds.xml) with 'localhost' everything was OK.
So I tried to replace it with 127.0.0.1 and got the same error.
Then I tried to put the ${jboss.bind.address} property back and changed JBOSS_IP in /etc/sysconfig/jbossas to 'localhost'.
Well, everything was working then.
So I returned JBOSS_IP=127.0.0.1 back and voila - everything is OK!!!
I tried it twice on two different machines. Once I used JBOSS_IP=localhost I was able to use any of the previously mentioned configuration and it was working. VERY STRANGE! After each change I restarted JBossAS completely.

I tried nslookup at the beginning to see if it is bound corectly:
[root at xen61 deploy]# nslookup 127.0.0.1
Server:         10.34.32.125
Address:        10.34.32.125#53

1.0.0.127.in-addr.arpa  name = localhost.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 07:44:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 07:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1569) Adding window
 properties
 with names starting with one of the letters from the range 'a-t'
In-Reply-To: <5795348.1184142571904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30026003.1187091841499.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1569?page=all ]

Thomas Heute resolved JBPORTAL-1569.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

Resolved, thanks for reporting this issue !

> Adding window properties with names starting with one of the letters from the range 'a-t'
> -----------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1569
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1569
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 Final
>            Reporter: Pavel Myshkin
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> When trying to add a window property of some window with the key name starting with letters a-s (upper or lower) you get an exception:
>  Cause: javax.portlet.PortletException: Expected submitted value of type Boolean for Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /WEB-INF/jsf/editProperties.xhtml][Class: javax.faces.component.html.HtmlForm,Id: _id55jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj][Class: javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: _id111jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj]}
> Message: Expected submitted value of type Boolean for Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /WEB-INF/jsf/editProperties.xhtml][Class: javax.faces.component.html.HtmlForm,Id: _id55jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj][Class: javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: _id111jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj]}
> StackTrace:
> javax.portlet.PortletException: Expected submitted value of type Boolean for Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /WEB-INF/jsf/editProperties.xhtml][Class: javax.faces.component.html.HtmlForm,Id: _id55jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj][Class: javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: _id111jbpns_2fadmin_2fdefault_2fAdminPortletWindowsnpbj]}
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:253)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:399)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
> 	at org.jboss.portal.faces.portlet.JSFMetaBridgePortlet.render(JSFMetaBridgePortlet.java:125)
> ......
> This does not happen with properties that the key starts with letters t-z.
> looks like it is somehow linked to the alphabetical position of the added key in relation to already existing window properties "Partial refresh" and "Region order". The key names that produced the exception are located before these properties in the list and the ones that did not generate the exception are located after these native 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 lists.jboss.org  Tue Aug 14 08:58:01 2007
From: jira-events at lists.jboss.org (Mike Khlu (JIRA))
Date: Tue, 14 Aug 2007 08:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-68) assert
 collection.remove(this) is fail
Message-ID: <28339829.1187096281133.JavaMail.jira@cloud.prod.atl2.jboss.com>

assert collection.remove(this) is fail
--------------------------------------

                 Key: HIBERNATE-68
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-68
             Project: Hibernate
          Issue Type: Task
            Reporter: Mike Khlu
         Assigned To: Steve Ebersole
            Priority: Minor


I've got simple ManyToMany case

class A {
  @ManyToMany
  Set<B> bes=...;
}

class B {
  @ManyToMany(mappedBy="bes")
  Collection<A> aes=...;

  void addAssociation(A newbie){
   // everything is clear. and works well
   ....
  }
  void removeAssociation(A associated){
     assert aes.remove(associated); // works fine
     assert a.bes.remove(this);   // doesn't works !!!
  }
}

if you try to run simple "exploit", you would be unhappy 

void foo(){
  A a = .... // gets poxy from session
  B b = a.iterator().next(); // gets proxy of associated entity by association

  b.removeAssociation(a); // we'll got a fail
} 

Of course, I know the cause:
1. method call would be delegated to entity (target) by proxy
2. so, "this" in method body means entity (target) not a proxy
3. We can't find entity in collection of proxies, in spite of we have proxy with such ID there

What do you think about 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 lists.jboss.org  Tue Aug 14 09:02:16 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Tue, 14 Aug 2007 09:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
Message-ID: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException after adding a google portlet to dashboard
---------------------------------------------------------------

                 Key: JBPORTAL-1629
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.8 Final
            Reporter: Roman Kalyakin
         Assigned To: Julien Viet
         Attachments: JBPORTAL-1629.patch

When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:02:17 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Tue, 14 Aug 2007 09:02:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21352647.1187096537037.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1629?page=all ]

Roman Kalyakin updated JBPORTAL-1629:
-------------------------------------

    Attachment: JBPORTAL-1629.patch

This patch seems to fix the problem. 

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Julien Viet
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:05:01 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Tue, 14 Aug 2007 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25059594.1187096701235.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1629?page=comments#action_12372007 ] 
            
Roman Kalyakin commented on JBPORTAL-1629:
------------------------------------------

A patch in attachment seems to fix the problem. It was introduced recently by adding a PortalAuthorizationManagerFactory property.

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Julien Viet
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:11:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 14 Aug 2007 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4607) Transaction timeout
 is not
 raising a JMSException in the JBossMQ Persistence manager or StateManager
Message-ID: <9458837.1187097061643.JavaMail.jira@cloud.prod.atl2.jboss.com>

Transaction timeout is not raising a JMSException in the JBossMQ Persistence manager or StateManager
----------------------------------------------------------------------------------------------------

                 Key: JBAS-4607
                 URL: http://jira.jboss.com/jira/browse/JBAS-4607
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


In JBossMQ, if something other than the jdbc2 PersistenceManager or StateManager
marks a transaction as "setRollbackOnly", e.g. a transaction timeout
then they both silently rollback the exception without throwing an Exception.

An Exception should be thrown to tell the caller that the operation 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 lists.jboss.org  Tue Aug 14 09:15:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 09:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1621) "title"
 attribute of "link" tag in jboss-portlet.xml is unhandled
In-Reply-To: <30538884.1186386229579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5659511.1187097301875.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1621?page=all ]

Thomas Heute resolved JBPORTAL-1621.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

> "title" attribute of "link" tag in jboss-portlet.xml is unhandled
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-1621
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1621
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>         Environment: JBoss Portal 2.6.1 GA bundled
>            Reporter: Pavel Myshkin
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> JBOSS-PORTLET.XML
> --------------------------------
> <!DOCTYPE portlet-app PUBLIC
>    "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
>    "dtd/jboss-portlet_2_6.dtd">
> <portlet-app>
> <portlet>
> <portlet-name>PortletName</portlet-name>
> <header-content>
> <!-- main calendar program -->
> <link rel="stylesheet" type="text/css" media="all" href="/calendar-win2k-cold-1.css"  title="win2k-cold-1"/>
> </header-content>
> </portlet>
> </portlet-app>
> Generates an error :
> Caused by: org.xml.sax.SAXException: Attribute "title" must be declared for element type "link". @ *unknown*[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 lists.jboss.org  Tue Aug 14 09:19:20 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:19:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-146) improve feedback when
 creating self referencing transitions
Message-ID: <14993915.1187097560953.JavaMail.jira@cloud.prod.atl2.jboss.com>

improve feedback when creating self referencing transitions
-----------------------------------------------------------

                 Key: GPD-146
                 URL: http://jira.jboss.com/jira/browse/GPD-146
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
    Affects Versions: jBPM JPDL Designer 3.1.0.GA
            Reporter: Koen Aers
         Assigned To: Koen Aers
            Priority: Minor


At the moment creating self referencing transitions is done by clicking twice on the source/target node. In the future some feedback (a dummy transition) should make this proces more obvious

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:21:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-24) add convenient way to
 create loop transitions
In-Reply-To: <28729967.1168955216880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28897891.1187097661065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-24?page=all ]

Koen Aers closed GPD-24.
------------------------

    Resolution: Done

I am closing this as it is now possible to create loop transitions by clicking twice on the source/target node. However GPD-146 was created because there are still improvements possible

> add convenient way to create loop transitions
> ---------------------------------------------
>
>                 Key: GPD-24
>                 URL: http://jira.jboss.com/jira/browse/GPD-24
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0 alpha1
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> the current workaround is to write the self-transition in xml.
> but this results in some *really* weird bendpoints when going back to the graphical 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 lists.jboss.org  Tue Aug 14 09:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-146) improve feedback when
 creating self referencing transitions
In-Reply-To: <14993915.1187097560953.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24971774.1187097781277.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-146?page=all ]

Koen Aers updated GPD-146:
--------------------------

    Component/s: jpdl

> improve feedback when creating self referencing transitions
> -----------------------------------------------------------
>
>                 Key: GPD-146
>                 URL: http://jira.jboss.com/jira/browse/GPD-146
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.GA
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Minor
>
> At the moment creating self referencing transitions is done by clicking twice on the source/target node. In the future some feedback (a dummy transition) should make this proces more obvious

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:23:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-143) Load the icon of a
 paletteContribution entry from the plugin directory where it is defined
In-Reply-To: <28132773.1186761253835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27215768.1187097781753.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-143?page=all ]

Koen Aers updated GPD-143:
--------------------------

    Component/s: jpdl

> Load the icon of a paletteContribution entry from the plugin directory where it is defined
> ------------------------------------------------------------------------------------------
>
>                 Key: GPD-143
>                 URL: http://jira.jboss.com/jira/browse/GPD-143
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Matthias Hanisch
>         Assigned To: Koen Aers
>
> In PaletteRoot class, the icon of a palette entry is always loaded from org.jbpm.gd.jpdl plugin, even if the paletteContribution entry is defined in a dependent plugin.
> The information, where the palette entry element (entryElement in PaletteRoot.addControls) is defined, can be found in entryElement.getContributor().getName().
> So also the corresponding image can be loaded from the correct bundle.
> [ Sorry to only give a verbal description of the implementation. I would sign a corporate contributor's agreement, but I have problems with the procedure, e.g.
> - do we need a corporate jboss account for my boss to sign
> - if we sign with the "corporate" account, with which account I need to contribute then
> etc.
> So I would need some assistance here. Then you would get a real diff also.
> ]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:40:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 14 Aug 2007 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4607) Transaction timeout
 is not raising
 a JMSException in the JBossMQ Persistence manager or StateManager
In-Reply-To: <9458837.1187097061643.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32026233.1187098801048.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4607?page=all ]

Adrian Brock closed JBAS-4607.
------------------------------

    Resolution: Done

Done. The fix is relatively trivial.

It involves only rolling back when we know there is an error
(we don't want to mask the real error if we know it)
i.e. something invoked setRollbackOnly on the TMS or Session.
otherwise we try to commit, which will raise an error if it timed out.

> Transaction timeout is not raising a JMSException in the JBossMQ Persistence manager or StateManager
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4607
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4607
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> In JBossMQ, if something other than the jdbc2 PersistenceManager or StateManager
> marks a transaction as "setRollbackOnly", e.g. a transaction timeout
> then they both silently rollback the exception without throwing an Exception.
> An Exception should be thrown to tell the caller that the operation 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 lists.jboss.org  Tue Aug 14 09:50:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26793975.1187099401189.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1629?page=all ]

Thomas Heute resolved JBPORTAL-1629.
------------------------------------

    Fix Version/s: 2.6.2 Final
       Resolution: Done
         Assignee: Thomas Heute  (was: Julien Viet)

Thanks a lot !

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 09:50:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1629)
 NullPointerException after adding a google portlet to dashboard
In-Reply-To: <13661653.1187096536852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2643386.1187099401350.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1629?page=all ]

Thomas Heute updated JBPORTAL-1629:
-----------------------------------

    Fix Version/s: 2.8 Final

> NullPointerException after adding a google portlet to dashboard
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1629
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1629
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final
>            Reporter: Roman Kalyakin
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: JBPORTAL-1629.patch
>
>
> When adding a "widget/google" type portlet to dashboard in the "configure dashboard" screen and switching back to dasboard, NullPointer exception is thrown. It is displayed in the browser window instead of dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 10:06:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 14 Aug 2007 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1294)
 JBP_CMS_WSP_PROP.PK unique contraint violated
In-Reply-To: <10327003.1172555376394.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9655904.1187100361987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1294?page=all ]

Thomas Heute resolved JBPORTAL-1294.
------------------------------------

    Resolution: Cannot Reproduce Bug
      Assignee: Thomas Heute

As mark it as "Cannot reproduce bug" unless you have a way to reproduce it.

> JBP_CMS_WSP_PROP.PK unique contraint violated
> ---------------------------------------------
>
>                 Key: JBPORTAL-1294
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1294
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.Alpha2
>         Environment: AS 4.0.5.GA
> Oracle 9i
>            Reporter: Ian White
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Try to create a content item using the CMS Admin Portlet.
> Get oracle sql exception - primary key unique contraint violated - JBP_CMS_SWP_PROP.PK:
> 16:32:14,171 INFO  [Http11BaseProtocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-80
> 16:32:14,328 INFO  [ChannelSocket] JK: ajp13 listening on /0.0.0.0:9
> 16:32:14,343 INFO  [JkMain] Jk running ID=0 time=0/78  config=null
> 16:32:14,359 INFO  [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 1m:12s:797ms
> 16:32:57,671 WARN  [JDBCExceptionReporter] SQL Error: 1, SQLState: 23000
> 16:32:57,671 ERROR [JDBCExceptionReporter] ORA-00001: unique constraint (JBPORTAL26.SYS_C0032370) violated
> 16:32:57,671 WARN  [JDBCExceptionReporter] SQL Error: 1, SQLState: 23000
> 16:32:57,671 ERROR [JDBCExceptionReporter] ORA-00001: unique constraint (JBPORTAL26.SYS_C0032370) violated
> 16:32:57,671 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
> org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
>         at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
>         at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
>         at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
>         at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
>         at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
>         at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
>         at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:41)
>         at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:969)
>         at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1114)
>         at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.loadManagedNode(PortalCMSCacheLoader.java:757)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.saveWSPPropNodeEntry(PortalCMSCacheLoader.java:560)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.put(PortalCMSCacheLoader.java:305)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.put(PortalCMSCacheLoader.java:389)
>         at org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader.prepare(PortalCMSCacheLoader.java:479)
>         at org.jboss.cache.interceptors.CacheStoreInterceptor.prepareCacheLoader(CacheStoreInterceptor.java:296)
>         at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:130)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
>         at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
>         at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
>         at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1491)
>         at org.jboss.tm.TransactionImpl.beforePrepare(TransactionImpl.java:1110)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:324)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
>         at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.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 lists.jboss.org  Tue Aug 14 10:06:02 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Tue, 14 Aug 2007 10:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-573) Draw blocks with
 FLUSH (join & state transfer)
In-Reply-To: <10915282.1187081941172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24332240.1187100362574.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-573?page=all ]

Vladimir Blagojevic resolved JGRP-573.
--------------------------------------

    Resolution: Done

Resolved. Change set:
JChannel.java 1.141 --> 1.142

> Draw blocks with FLUSH (join & state transfer)
> ----------------------------------------------
>
>                 Key: JGRP-573
>                 URL: http://jira.jboss.com/jira/browse/JGRP-573
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> To reproduce:
> #1 Get the latest from CVS head
> #2 Start 1 Draw: java org.jgroups.demos.Draw -props ./flush-udp.xml -state -use_blocking
> - The flush-udp.xml config was copied from JGroups/conf and not modified
> - use_blocking sets the Channel to use blocking
> #3 Draw some points into Draw 
> #4 Start a second instance of Draw
> RESULT: the second instance does join correctly and also transfers the state correctly, but it hangs on FLUSH:
> [linux]/home/bela$ draw -props ./flush-udp.xml -state -use_blocking
> -------------------------------------------------------
> GMS: address is 192.168.0.5:33755
> -------------------------------------------------------
> --  received BlockEvent
> ** View=[192.168.0.5:33754|1] [192.168.0.5:33754, 192.168.0.5:33755]
> read state: 139 entries
> -- received UnblockEvent
> 0 [WARN] [main] JChannel.connect(): 192.168.0.5:33755 waiting on UNBLOCK after connect timed 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 lists.jboss.org  Tue Aug 14 10:10:02 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 14 Aug 2007 10:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16318807.1187100602640.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372028 ] 
            
Paul Gier commented on JBAOP-453:
---------------------------------


I think it's fine to specify dependencies of the plugin in the plugin's pom.xml.  If these dependencies (jboss-aop, plexus-utils, etc) are required to compile and run the plugin then they should be in the plugin pom.xml.  These dependencies will only be used by the client at build time.  If some of them are required at runtime, then the client project should specify the dependencies in it's own pom.xml in a runtime or compile scope.

If the client requires additional dependencies to run the plugin, then those can be defined as dependencies of the plugin in the client pom.
Unfortunately, maven doesn't allow you to exclude (and redifine) plugin dependencies like you can with regular transitive dependencies.  By putting the client defined plugin dependencies first in the forked classpath, that should allow you to override which version of jboss-aop the plugin uses.  I think this is similar to what you suggested in number 2.

Which dependencies are you talking about moving?  It seems like it would be more difficult for the user if the plugin doesn't have it's own default dependencies defined.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Tue Aug 14 10:10:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 14 Aug 2007 10:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1026) Refactor
 extended persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19336434.1187100602900.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1026?page=all ]

Carlo de Wolf updated EJBTHREE-1026:
------------------------------------

    Priority: Critical  (was: Major)

> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Tue Aug 14 10:28:02 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 10:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8941760.1187101682214.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=comments#action_12372033 ] 
            
Joe Son commented on JBRULES-1081:
----------------------------------

I've moved the contents of the extracted standalone version to my C drive. (Windows env). Had to add additional env. variable (JAVA_HOME2) and modify all the config files to point to it. (Catalina, setup, setclass etc). 

I'm wondering if there was data corruption because the server did not start properly the first time? I had to stop and restart several times before I got the configuration right.

Hope this helps.

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 10:52:08 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 10:52:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1042) Investigate
 possible casting issue with message bridge
In-Reply-To: <5137497.1186667449514.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1636508.1187103128793.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1042?page=all ]

Tim Fox closed JBMESSAGING-1042.
--------------------------------

    Resolution: Done

> Investigate possible casting issue with message bridge
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1042
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1042
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>         Attachments: JBMESSAGING-1042.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 lists.jboss.org  Tue Aug 14 10:57:01 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 10:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8923435.1187103421188.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=comments#action_12372040 ] 
            
Joe Son commented on JBRULES-1081:
----------------------------------

I've installed new copy of the standalone version. (Got Rid of old one).
I've found that Xalan jar file is missing from the Standalone version.  I've removed existing repository directory and xml file in an effort to make sure the entire process works. (i.e. starting the server should create the directory if it doesn't exists)

I've also modified all batch files to make sure they point to new java home with JDK1.5. Previously I missed it on few batch files.  This seem to work for most part. I'm still having issues with being able to access all parts of BRMS.  I feel like there are still configuration issues to be resolved.  

1. Logout points to 404 page.  This maybe redirect setting issue? 
2. Accessing cerntain DRL file returns error.
3. Still Not sure how to set up logging.properites file to generate error log on localhost.<date> file.

Any comments or questions?

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:10:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-983) Messages can
 be delivered after connection is stopped
In-Reply-To: <20962966.1181209274478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16274461.1187104201431.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-983?page=all ]

Tim Fox updated JBMESSAGING-983:
--------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Messages can be delivered after connection is stopped
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-983
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-983
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> Stopping a connection does not currently block until all current onMessage invocations are complete, as per JMS spec.
> We need to make sure it 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 lists.jboss.org  Tue Aug 14 11:12:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1036) Consider
 createing JBossDestination interface
In-Reply-To: <10696945.1186598809453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12586267.1187104321265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1036?page=all ]

Tim Fox closed JBMESSAGING-1036.
--------------------------------

    Resolution: Won't Fix

Seems like a Spring bug.

> Consider createing JBossDestination interface
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1036
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1036
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> To solve forum 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 lists.jboss.org  Tue Aug 14 11:12:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-908) MySQL on Linux
 fails to load server after failover
In-Reply-To: <21443708.1172746149080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22805949.1187104321878.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-908?page=all ]

Tim Fox closed JBMESSAGING-908.
-------------------------------

    Resolution: Won't Fix

Am 99.9% sure this is due to using a non transacted datastore so closing.

> MySQL on Linux fails to load server after failover
> --------------------------------------------------
>
>                 Key: JBMESSAGING-908
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-908
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Sometimes, after failover occurs and a server is restarted, the server start fails with:
> java.lang.IllegalStateException: Did not load correct number of messages, wanted:1 but got:0
> 	at org.jboss.messaging.core.PagingChannelSupport.processReferences(PagingChannelSupport.java:591)
> 	at org.jboss.messaging.core.PagingChannelSupport.doLoad(PagingChannelSupport.java:518)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.LocalClusteredQueue.mergeIn(LocalClusteredQueue.java:243)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.performFailover(DefaultClusteredPostOffice.java:2169)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.nodeLeft(DefaultClusteredPostOffice.java:2031)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.access$1800(DefaultClusteredPostOffice.java:98)
> 	at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$HandleViewAcceptedRunnable.run(DefaultClusteredPostOffice.java:2400)
> 	at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
> 	at java.lang.Thread.run(Thread.java:595
> or similar.
> Analysing logs it seems this is because when the server crashed previously it did so and partially committed a transaction, i.e inserted the ref but not the message.
> My suspicion is that this is because the MySQL configuration being used is setup to use the non transaction myISAAM storage which has no transaction  support. But this needs to be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:12:02 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 11:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-838) Test scenario
 where no failover has occurred on server side...
In-Reply-To: <4920923.1171498965960.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25143347.1187104322147.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-838?page=all ]

Tim Fox updated JBMESSAGING-838:
--------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Test scenario where no failover has occurred on server side...
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-838
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-838
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.2.0.Beta2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Optional
>             Fix For: 2.0.0 Beta 1
>
>
> When a client thinks the server has failed e.g. the netwrk between client--server temporarily fails but the network between server--server is ok, the server will return -1 to say no failover is occurring or times out then the client will retry the orginal node after a pause.
> The pause needs to be made configurable and a test devised to test this 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 lists.jboss.org  Tue Aug 14 11:16:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 14 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27189207.1187104561361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1027?page=all ]

Clebert Suconic reassigned JBMESSAGING-1027:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:16:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 14 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-574) UnicastChannelTest
	doesn't work
Message-ID: <8228116.1187104561702.JavaMail.jira@cloud.prod.atl2.jboss.com>

UnicastChannelTest doesn't work
-------------------------------

                 Key: JGRP-574
                 URL: http://jira.jboss.com/jira/browse/JGRP-574
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


Messages are not received 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 11:24:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 11:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-81) Add support for
 reconnecting transitions
In-Reply-To: <898355.1178879092359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23117778.1187105041738.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-81?page=all ]

Koen Aers closed GPD-81.
------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

A small present for christmas for Ronald ;-)

> Add support for reconnecting transitions
> ----------------------------------------
>
>                 Key: GPD-81
>                 URL: http://jira.jboss.com/jira/browse/GPD-81
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: Clean eclipse 3.2.2 and gpd 3.1alpha4
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> Not being able to reconnect transitions graphically from e.g. node a to node b is still a big omission for the gpd to be used by 'grey suites' as well as 'jeans and t-shirts', at least within our company. I thought there was a long standing issue for this, but I cannot find it. 
> If someone could point me to a place to start looking into this, I'd be happy to try to implement this (but it will be the only gpd thing I 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 lists.jboss.org  Tue Aug 14 11:58:10 2007
From: jira-events at lists.jboss.org (no way (JIRA))
Date: Tue, 14 Aug 2007 11:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1082) minor changes to
 the drools documentation
Message-ID: <15164549.1187107090966.JavaMail.jira@cloud.prod.atl2.jboss.com>

minor changes to the drools documentation
-----------------------------------------

                 Key: JBRULES-1082
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1082
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.GA
            Reporter: no way
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


In the documentation [ver 4.0.0]
[not using the numbering because latest version -> different numbering]
===================
chapter :
The rule language 
    -> Rule
        -->Left Hand Side Conditional Elements
            ->operators
misspelled operator :  in the documentation memberof is used, whilst in drools memberOf should be used [case thingie]

====================
chapter :
The rule language 
    -> Rule
        -->Left Hand Side Conditional Elements
            ->> forall

example : combining forall with Not CE
in own testing the not forall  like used in the example doesnt seem to work
when adding parenthesis the problem is resolved
i.e.
when
   not (  <- add this one
            forall (things_here)
          ) <- add this 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 lists.jboss.org  Tue Aug 14 12:23:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-190) webservice
 descriptors generation tool
Message-ID: <26672132.1187108581255.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-190?page=all ]

Alejandro Guizar updated BPEL-190:
----------------------------------

    Summary: webservice descriptors generation tool  (was: web app generation tool)

> webservice descriptors 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.2 GA
>
>
> 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 lists.jboss.org  Tue Aug 14 12:27:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 14 Aug 2007 12:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1038) Client side
 failover hopping does not work
In-Reply-To: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23200347.1187108821549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1038?page=all ]

Clebert Suconic reassigned JBMESSAGING-1038:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Client side failover hopping does not work
> ------------------------------------------
>
>                 Key: JBMESSAGING-1038
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.
> if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".
> Instead it should iterate through the list of delegates trying each one in turn.
> Need to write a test for this 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 lists.jboss.org  Tue Aug 14 12:44:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 14 Aug 2007 12:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-4532) Track JBoss and
 thirdparty dependencies for JBossAS 4.4.x
Message-ID: <20912203.1187109841271.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4532?page=all ]

Dimitris Andreadis deleted JBAS-4532:
-------------------------------------


> Track JBoss and thirdparty dependencies for JBossAS 4.4.x
> ---------------------------------------------------------
>
>                 Key: JBAS-4532
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4532
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>
> Parent task to track jboss and thirdparty library dependencies/upgrades for JBossAS 4.4.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 lists.jboss.org  Tue Aug 14 12:52:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-218) make the imported
 wsdl documents a source of partner service descriptions
In-Reply-To: <17113795.1166408025580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25884971.1187110321145.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-218?page=all ]

Alejandro Guizar updated BPEL-218:
----------------------------------

        Summary: make the imported wsdl documents a source of partner service descriptions  (was: use imported documents as a service catalog)
    Description: Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.  (was: Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in trivial scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner information is the list of imported documents.)

> make the imported wsdl documents a source of partner service descriptions
> -------------------------------------------------------------------------
>
>                 Key: BPEL-218
>                 URL: http://jira.jboss.com/jira/browse/BPEL-218
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.2 GA
>
>
> Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 12:56:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-275) web module deployment
	tool
Message-ID: <8332987.1187110561120.JavaMail.jira@cloud.prod.atl2.jboss.com>

web module deployment tool
--------------------------

                 Key: BPEL-275
                 URL: http://jira.jboss.com/jira/browse/BPEL-275
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Engine
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1 GA


Develop a tool for deploying web modules to the application server. Use JSR-88 APIs if possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 12:58:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 12:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-275) web module deployment
	tool
In-Reply-To: <8332987.1187110561120.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9146206.1187110681430.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-275?page=all ]

Alejandro Guizar updated BPEL-275:
----------------------------------

     Original Estimate: 1 week
    Remaining Estimate: 1 week

> web module deployment tool
> --------------------------
>
>                 Key: BPEL-275
>                 URL: http://jira.jboss.com/jira/browse/BPEL-275
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Develop a tool for deploying web modules to the application server. Use JSR-88 APIs if possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:00:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 14 Aug 2007 13:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-218) make the imported
 wsdl documents a source of partner service descriptions
In-Reply-To: <17113795.1166408025580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23753667.1187110801392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-218?page=all ]

Alejandro Guizar updated BPEL-218:
----------------------------------

     Original Estimate: 3 days
    Remaining Estimate: 3 days

> make the imported wsdl documents a source of partner service descriptions
> -------------------------------------------------------------------------
>
>                 Key: BPEL-218
>                 URL: http://jira.jboss.com/jira/browse/BPEL-218
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.2 GA
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:02:01 2007
From: jira-events at lists.jboss.org (Przemyslaw Dej (JIRA))
Date: Tue, 14 Aug 2007 13:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-165) Nukes forums to
 JBoss Forums migration scripts
In-Reply-To: <30384231.1169689014154.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1229054.1187110921930.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-165?page=all ]

Przemyslaw Dej resolved JBFORUMS-165.
-------------------------------------

    Resolution: Done

> Nukes forums to JBoss Forums migration scripts
> ----------------------------------------------
>
>                 Key: JBFORUMS-165
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-165
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum Model Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Przemyslaw Dej
>            Priority: Blocker
>             Fix For: 1.1.0 Alpha
>
>          Time Spent: 1 week, 2 days
>
> We need to update migration scripts and test them properly. Later we should make them available in JBoss Forums downloads in migration category. Plus a small instruction how to use them in the guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:06:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Aug 2007 13:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4608) Consider adding
 FLUSH to channels in Branch_4_x
Message-ID: <21081239.1187111161233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Consider adding FLUSH to channels in Branch_4_x
-----------------------------------------------

                 Key: JBAS-4608
                 URL: http://jira.jboss.com/jira/browse/JBAS-4608
             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.2.2.GA


David Ward experienced problems with virtual synchrony in demo apps he was running on 4.2.1.GA.  These were resolved by adding FLUSH to the cluster-service.xml stack.  Need to consider whether we should add FLUSH to the standard stacks in 4.2.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 lists.jboss.org  Tue Aug 14 13:16:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Aug 2007 13:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4608) Consider adding
 FLUSH to channels in Branch_4_x
In-Reply-To: <21081239.1187111161233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13269997.1187111761320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4608?page=all ]

Brian Stansberry updated JBAS-4608:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116104

> Consider adding FLUSH to channels in Branch_4_x
> -----------------------------------------------
>
>                 Key: JBAS-4608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4608
>             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.2.2.GA
>
>
> David Ward experienced problems with virtual synchrony in demo apps he was running on 4.2.1.GA.  These were resolved by adding FLUSH to the cluster-service.xml stack.  Need to consider whether we should add FLUSH to the standard stacks in 4.2.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 lists.jboss.org  Tue Aug 14 13:18:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 13:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1024) Distributed
 queue stops working when node is killed
In-Reply-To: <3119231.1186596736249.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29104460.1187111881899.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1024?page=all ]

Tim Fox closed JBMESSAGING-1024.
--------------------------------

    Resolution: Done

> Distributed queue stops working when node is killed
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1024
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1024
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> If start a test with 3 nodes, then kill one of them then the distributed queue doesn't work.
> Try starting DistributedRequestResponseTest with 3 nodes then killing to replicate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:34:01 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Aug 2007 13:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4605) JSP compiler won't
 compile JDK 1.5 source
In-Reply-To: <24809083.1187034901682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22285485.1187112841107.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4605?page=all ]

Stan Silvert resolved JBAS-4605.
--------------------------------

    Fix Version/s: JBossAS-4.2.2.GA
       Resolution: Done

Added this to web.xml:

<init-param>
         <param-name>compilerSourceVM</param-name>
         <param-value>1.5</param-value>
</init-param>


> JSP compiler won't compile JDK 1.5 source
> -----------------------------------------
>
>                 Key: JBAS-4605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4605
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>             Fix For: JBossAS-4.2.2.GA
>
>
> From the comments in conf/web.xml, it looks like the JSP servlet should detect the JVM version and then set compilerTargetVM and compilerSourceVM automatically.   This is not working as a JSP with JDK 1.5 source will not compile.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 13:40:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 13:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1025) Add test in
 GroupManagementTest
In-Reply-To: <24748680.1186597189354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1768455.1187113201090.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1025?page=all ]

Tim Fox updated JBMESSAGING-1025:
---------------------------------

    Fix Version/s: 2.0.0 Beta 1
                       (was: 1.4.0.CR2)

> Add test in GroupManagementTest
> -------------------------------
>
>                 Key: JBMESSAGING-1025
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1025
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> .... that tests that failover map is created in vew order

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:04:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Tue, 14 Aug 2007 16:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29403184.1187121841140.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-449?page=comments#action_12372120 ] 
            
Anders Andersen commented on JBAOP-449:
---------------------------------------

1) I have testet the multiple aoppaths by

              <aoppaths>
                <aoppath>
                  ${basedir}/../jboss-portal-sar/src/main/resources/portal-aop.xml 
                </aoppath>
                <aoppath>
                  ${basedir}/src/main/resources/base-aop.xml
                </aoppath>
              </aoppaths>

AND IT WORKS !!!!

2) At the same time I have testet the default...

      else
         return "src/main/resources/jboss-aop.xml";

IT DOES NOT WORK
The problem is process current directory. If it is inside the maven module it works if it is outside it does not work
And for any larger build it will be outside !!!!

There has to be put ${basedir} in front of it.
Code like
      else
         return new File(project.getBasedir(),"src/main/resources/jboss-aop.xml").getName();






> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 16:06:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Tue, 14 Aug 2007 16:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26871065.1187121961302.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Anders Andersen reopened JBAOP-449:
-----------------------------------

             
${basedir} must be added to the default.

      else
         return new File(project.getBasedir(),"src/main/resources/jboss-aop.xml").getName();

(my code sample is not testet!!!)

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Tue Aug 14 16:08:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Aug 2007 16:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4554) Extract clustering
 stuff from
 testsuite/build.xml into imports/config/tests-clustering.xml
In-Reply-To: <23944399.1184513043676.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <891438.1187122081367.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4554?page=all ]

Brian Stansberry closed JBAS-4554.
----------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                       (was: JBossAS-5.0.0.CR1)
       Resolution: Done

> Extract clustering stuff from testsuite/build.xml into imports/config/tests-clustering.xml
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4554
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Optional
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> A la what Anil did for tests-jacc in Branch_4_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 lists.jboss.org  Tue Aug 14 16:25:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Tue, 14 Aug 2007 16:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2290054.1187123101553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

John Ruud updated GPD-78:
-------------------------


Koen,

This now appears to work for me!

Thanks, John

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Tue Aug 14 16:33:08 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 16:33:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7629856.1187123588083.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=comments#action_12372126 ] 
            
Joe Son commented on JBRULES-1081:
----------------------------------

Hey Guys, you can close this particular bug.
This was all configuration.
If anyone is trying to run this and having issues, please make sure all your batch files are pointing to correct java home.  In Window's env, you may want to create secondary env and point it to JDK1.5.

Other issues with Standalone I've come across was client side javascript error and logout redirect issues.
Not sure if these are configuration or not.

thank you.

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:33:08 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Tue, 14 Aug 2007 16:33:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15933953.1187123588232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=all ]

Joe Son updated JBRULES-1081:
-----------------------------

    Priority: Minor  (was: Major)

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>            Priority: Minor
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:37:01 2007
From: jira-events at lists.jboss.org (Hany Mesha (JIRA))
Date: Tue, 14 Aug 2007 16:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3982)
 HASingletonController emits a
 cluster-wide JMX Notification after starting/stopping singleton
In-Reply-To: <26865730.1168626292592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13238544.1187123821709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3982?page=all ]

Hany Mesha reassigned JBAS-3982:
--------------------------------

    Assignee: Hany Mesha  (was: Brian Stansberry)

> HASingletonController emits a cluster-wide JMX Notification after starting/stopping singleton
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3982
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3982
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Hany Mesha
>             Fix For: JBossAS-5.0.1.CR1
>
>
> Provide a mechanism for cluster-wide notifications when singleton services are started and stopped.
> In conjunction with this, a special BarrierController variant could be developed that monitors the cluster-wide notifications, allowing service dependencies on remote singletons.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 16:37:02 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 16:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13345403.1187123822033.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-78?page=comments#action_12372128 ] 
            
Koen Aers commented on GPD-78:
------------------------------

Thanks John, I'll close the issue and get ready for the GA release!

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Tue Aug 14 16:37:02 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 16:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-78) configInfoElements of
 semantic elements are not always added to XML adapters
In-Reply-To: <24892360.1178748532343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3667268.1187123822722.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-78?page=all ]

Koen Aers closed GPD-78.
------------------------

    Resolution: Done

> configInfoElements of semantic elements are not always added to XML adapters
> ----------------------------------------------------------------------------
>
>                 Key: GPD-78
>                 URL: http://jira.jboss.com/jira/browse/GPD-78
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>         Attachments: GPD-78.patch
>
>
> For example, if a node that contains an Action with a non-empty configInfoElements collection is added to the diagram, the configInfoElements collection is not assigned in the ActionDomAdapter. 
> I added the following line to the end of the "if (action != null)" clause in ActionDomAdapter.initialize(): 
> addElements(action.getConfigInfoElements()); 
> .. and then things seems to work. I believe this is similar to for example how the events collection is currently initialized in DecisionDomAdapter.initialize(), while of course there may be side effects that I'm not aware of. 
> It would be great if a fix (possibly the one described above) can be included in GD 3.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 lists.jboss.org  Tue Aug 14 16:54:14 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 16:54:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1032) Problem with
 bridge when source is remote
In-Reply-To: <25187402.1186598044726.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13744576.1187124854446.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1032?page=all ]

Tim Fox closed JBMESSAGING-1032.
--------------------------------

    Resolution: Rejected

Looks like user error.

Remote JMS provider needs to be configured to use global JNDI namespace

> Problem with bridge when source is remote
> -----------------------------------------
>
>                 Key: JBMESSAGING-1032
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1032
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Need to investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 17:02:02 2007
From: jira-events at lists.jboss.org (Steven Holmes (JIRA))
Date: Tue, 14 Aug 2007 17:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10458228.1187125322322.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12372139 ] 
            
Steven Holmes commented on JBPORTAL-1626:
-----------------------------------------

I think this is the same issue:

13:52:45,052 ERROR [DefaultPageControlPolicy] Rendering portlet window  produced an error
java.lang.NullPointerException
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:235)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$Transactio
nInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNe
xt(TransactionInterceptor$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNe
xt(TransactionInterceptor$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNe
xt(TransactionInterceptor$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchr
onizationInterceptor.java:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherIntercept
or.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        at sun.reflect.GeneratedMethodAccessor351.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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.jav
a:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$Prod
ucerPortletInvoker$invoke$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(Produc
erPortletInvoker$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(Produc
erPortletInvoker$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(Produc
erPortletInvoker$invoke_N8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService
.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerServi
ce.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManageme
ntInterceptorImpl.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchron
izationInterceptor.java:116)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$Ins
tanceContainerImpl$invoke$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(Instan
ceContainerImpl$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(Instan
ceContainerImpl$invoke_N8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(Instan
ceContainerImpl$invoke_N8654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:24
0)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericC
ontentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105
)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.
java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)

        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.jav
a:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.jav
a:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor
.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.
java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)

        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.jav
a:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.jav
a:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor
.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHan
dler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:7
9)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler
.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelect
or.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.jav
a:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerIntercepto
r.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionI
nterceptor$invoke$aop(TransactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(Transactio
nInterceptor$invoke_N5143606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(Transactio
nInterceptor$invoke_N5143606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(Transactio
nInterceptor$invoke_N5143606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)



> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 17:06:06 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Tue, 14 Aug 2007 17:06:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
Message-ID: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>

Brackets are not always optional for non-existential quantifier "not" 
----------------------------------------------------------------------

                 Key: JBRULES-1083
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Markus Reitz
         Assigned To: Mark Proctor
            Priority: Minor


According to the documentation, brackets are optional as illustrated by

  Example 6.37. No Busses

  not Bus()

In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)

  package test

  rule "Brackets"

    when
      not exists(x : SpecialString() and
                 forall(y : SpecialString(this!=x)
                            SpecialString(this==y, text=="Universe")))

    then
      System.out.println("Condition satisfied");
  end

this is not true. Trying to load this rule leads to

org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
at org.drools.rule.Package.checkValidity(Package.java:408)
at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
at DroolsTest.<init>(Unknown Source)
at DroolsTest.main(Unknown Source)

When brackets are added:

  package test

  rule "Brackets"

    when
      not(exists(x : SpecialString() and
                 forall(y : SpecialString(this!=x)
                            SpecialString(this==y, text=="Universe"))))

    then
      System.out.println("Condition satisfied");
  end

rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 17:08:01 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 14 Aug 2007 17:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
Message-ID: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>

Removing elements directly from source editor doesnt update the model and adater
--------------------------------------------------------------------------------

                 Key: GPD-147
                 URL: http://jira.jboss.com/jira/browse/GPD-147
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
            Reporter: Imran Naqvi
         Assigned To: Koen Aers


When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:

public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
		if (changedFeature != null) {
			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
		} else if (INodeNotifier.ADD == eventType) {
			handleDomAdd(newValue);
		} else if (INodeNotifier.REMOVE == eventType) {
			handleDomRemove(oldValue);
		}
	}

When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 17:46:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17707806.1187127961666.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-147?page=comments#action_12372157 ] 
            
Koen Aers commented on GPD-147:
-------------------------------

There are still a lot of issues with the synchronization of the xml page and the graphical page. They will not be fixed for the upcoming GA, but surely need to be fixed over time after this release.
Everybody is welcome to add any other problems one might have with this.

Thanks,
Koen

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 17:48:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Tue, 14 Aug 2007 17:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24591131.1187128081232.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372158 ] 
            
John Ruud commented on GPD-77:
------------------------------

Koen,

XmlAdapter.initialize(SemanticElement) is invoked when loading the PD diagram, but not when adding objects from the palette (which is when I need to initialize my semantic elements), so I don't believe this approach would work.

I'm not very familiar with the design behind GD, but my first thought was that it was the semantic elements (the "model objects"?) themselves that should get initialized, and that the xml adapters etc. would just get updated to reflect this (obviously this is not the case when reading the xml, when the xml adapters are used to re-create the semantic elements). Because of this it seems to me like the GD should provide some way of creating initialized semantic elements, for example by invoking some SemanticElement.initializeNew() - like method. This code would get invoked when adding objects from the palette (I think that may be the only case), but not for example while loading the diagram from xml (however, I'm leaving the design up to you - I just need one way to do this).

Thanks, John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Tue Aug 14 17:58:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 17:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28628049.1187128681146.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-147?page=all ]

Koen Aers closed GPD-147.
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

Thanks to your accurate description, I have done the change you suggest. Let me know if it helps and feel free to reopen this bug or file another if necessary.

Thanks again,
Koen

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 18:05:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 18:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3326461.1187129101526.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372164 ] 
            
Koen Aers commented on GPD-77:
------------------------------

John,

What is wrong with doing this in the constructor of the SemanticElement?

Regards,
Koen

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Tue Aug 14 18:13:01 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 14 Aug 2007 18:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12935856.1187129581435.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-147?page=comments#action_12372167 ] 
            
Imran Naqvi commented on GPD-147:
---------------------------------

sweet! thanx a lot...I'll test it out.

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 18:23:05 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Tue, 14 Aug 2007 18:23:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1902751.1187130185055.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372168 ] 
            
Koen Aers commented on GPD-77:
------------------------------

So I answered to quickly (it is already past midnight here ;-) )

The solution for your problem is using either the initialize() method or do the initialization in the constructor. If the constructor or the initialize() method gets called when reading the diagram from the xml, you *have* to make sure in the adapter that the proper values for the attributes and nested elements are written into the newly created (and possibly wrongly initialized) semantic element object. This is done by the XmlAdapter.initialze(SemanticElement) method for the XmlAdapter of this particular semantic element.

Have e.g. a look at the Task/TaskDomAdapter combo. Newly created instances of a task have attributes initialized to particular values. The initalize(SemanticElement) method in TaskDomAdapter will override these attributes with the values found in the xml.

Hope this helps,
Koen

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Tue Aug 14 18:23:05 2007
From: jira-events at lists.jboss.org (Imran Naqvi (JIRA))
Date: Tue, 14 Aug 2007 18:23:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-147) Removing elements
 directly from source editor doesnt update the model and adater
In-Reply-To: <4166240.1187125681274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15315910.1187130185215.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-147?page=comments#action_12372169 ] 
            
Imran Naqvi commented on GPD-147:
---------------------------------

seems to work fine. Thanks.

> Removing elements directly from source editor doesnt update the model and adater
> --------------------------------------------------------------------------------
>
>                 Key: GPD-147
>                 URL: http://jira.jboss.com/jira/browse/GPD-147
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>            Reporter: Imran Naqvi
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> When I make a change the xml directly from the source page, particularly if i remove an element, the change doesnt get reflected in the adapter and model. Hence when I come back to the graph page the element remains there although it has been removed from the xml.
> For example, in any process definition go to the source page and delete a node from there, then go back to the graph page, the node will still be there. I found that the problem is in this method in XmlAdapter:
> public void notifyChanged(INodeNotifier notifier, int eventType, Object changedFeature, Object oldValue, Object newValue, int pos) {
> 		if (changedFeature != null) {
> 			doModelUpdate(((Node)changedFeature).getNodeName(), (String)newValue);
> 		} else if (INodeNotifier.ADD == eventType) {
> 			handleDomAdd(newValue);
> 		} else if (INodeNotifier.REMOVE == eventType) {
> 			handleDomRemove(oldValue);
> 		}
> 	}
> When an element is removed this method is called with the corect event type which is remove, so handleDomRemove should be called (which would call the doModelRemove method), but instead the doModelUpdate is called instead since changedFeature is not null (never is). I am not absolutely sure why the first check is there so I cant suggest a fix but as far as I can see that first if statement should be moved to the 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 lists.jboss.org  Tue Aug 14 19:00:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-301) Use Hermes in
 top of Messaging
Message-ID: <22313526.1187132401294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-301?page=all ]

Tim Fox updated JBMESSAGING-301:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> Use Hermes in top of Messaging
> ------------------------------
>
>                 Key: JBMESSAGING-301
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-301
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: Unscheduled
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:02:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-737) Automate
 MemoryLeak tests on cruisecontrol
In-Reply-To: <6979308.1168451427306.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9694353.1187132521246.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-737?page=all ]

Tim Fox updated JBMESSAGING-737:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> Automate MemoryLeak tests on cruisecontrol
> ------------------------------------------
>
>                 Key: JBMESSAGING-737
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-737
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: Unscheduled
>
>
> MemoryLeak tests are dependent on JBossProfiler library. I need to verify binary dependencies on cruisecontrol 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 lists.jboss.org  Tue Aug 14 19:02:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-574) In memory
 replication of persistent messages
In-Reply-To: <32027069.1159809401687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10511966.1187132521724.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-574?page=all ]

Tim Fox updated JBMESSAGING-574:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> In memory replication of persistent messages
> --------------------------------------------
>
>                 Key: JBMESSAGING-574
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-574
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: Unscheduled
>
>
> We should enable an option whereby persisted messages can be replicated between nodes rather than persisted to disk

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:02:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1016) Find some way
 of speeding up the test suite
In-Reply-To: <16171804.1184778047440.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30368661.1187132521852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1016?page=all ]

Tim Fox closed JBMESSAGING-1016.
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)
       Resolution: Duplicate Issue

> Find some way of speeding up the test suite
> -------------------------------------------
>
>                 Key: JBMESSAGING-1016
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1016
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: Unscheduled
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:04:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1021) Move client
 side transaction state to the server side
In-Reply-To: <1163351.1185399527336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29795917.1187132641257.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1021?page=comments#action_12372171 ] 
            
Tim Fox commented on JBMESSAGING-1021:
--------------------------------------

A negative point to this is that maintaining transactional state on the server side makes failover more difficult since that state needs to be synchronously replicated to the buddy.

> Move client side transaction state to the server side
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1021
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1021
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 1
>
>
> Currently we hold the incomplete JMS transactional state on the client side and send it all in one go on commit.
> Instead we should store it on the server side. This will simplify things and allow larger transactions to be built without a large pause on commit or exhausting client side memory

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:04:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-380) Use JBoss retro
Message-ID: <31415193.1187132641627.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-380?page=all ]

Tim Fox closed JBMESSAGING-380.
-------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)
       Resolution: Rejected

We are now Java 5 only

> Use JBoss retro
> ---------------
>
>                 Key: JBMESSAGING-380
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-380
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: Unscheduled
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We should consider using JBossRetro in JBossMessaging. This will allow us to use JDK1.5 specific features in the code base, but will still run on JDK1.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 lists.jboss.org  Tue Aug 14 19:04:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-697) Convert crash
 tests to use new server management framework
In-Reply-To: <4077302.1166743838482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20522809.1187132641968.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-697?page=all ]

Tim Fox closed JBMESSAGING-697.
-------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: 2.0.0 Beta 1)
       Resolution: Done

> Convert crash tests to use new server management framework
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-697
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-697
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.4.0.CR2
>
>
> Now the testing framework supports the ability to kill and restart servers we should transfer the crash tests across to this new way of doing 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 lists.jboss.org  Tue Aug 14 19:06:13 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-750) Remove manually
 spawning of servers from runtest and build.xml
In-Reply-To: <29080858.1169026612896.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20668044.1187132773563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-750?page=all ]

Tim Fox closed JBMESSAGING-750.
-------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: 2.0.0 Beta 1)
       Resolution: Done
         Assignee: Tim Fox

> Remove manually spawning of servers from runtest and build.xml
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-750
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-750
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.4.0.CR2
>
>
> Both runtest and tests/build.xml still use startrmiserver to start (and stop) remote servers prior (and after) to test run.
> The test framework now has the ability to start servers programmatically so this should be unnecessary. Removing it wil aid clarity of test scripts

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:06:13 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-222) Run "findbugs"
 on the code base
Message-ID: <20542732.1187132773751.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-222?page=all ]

Tim Fox updated JBMESSAGING-222:
--------------------------------

    Fix Version/s: Unscheduled
                       (was: 2.0.0 Beta 1)

> Run "findbugs" on the code base
> -------------------------------
>
>                 Key: JBMESSAGING-222
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-222
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: Unscheduled
>
>         Attachments: build.xml, findbugs-0.9.5.zip, findbugs.patch, findbugs.patch, report-fb.xml
>
>
> Run "findbugs" or similar regularily on the code base. Integrate it in the continous build 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 lists.jboss.org  Tue Aug 14 19:10:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases, also DB2
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12725703.1187133001100.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1026?page=comments#action_12372173 ] 
            
Tim Fox commented on JBMESSAGING-1026:
--------------------------------------

DB2 will take a bit extra work. So putting the DB2 work in a different task

> Ensure successfull test run against all supported databases, also DB2
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:10:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1048) Test DB2
 config against Hudson
Message-ID: <16680822.1187133001211.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test DB2 config against Hudson
------------------------------

                 Key: JBMESSAGING-1048
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1048
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 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 lists.jboss.org  Tue Aug 14 19:15:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-742) Update of
 JBossRemoting to Alpha4 and JBMESSAGING-741
In-Reply-To: <15501215.1168535007057.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29297509.1187133301191.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-742?page=all ]

Tim Fox reopened JBMESSAGING-742:
---------------------------------

             

> Update of JBossRemoting to Alpha4 and JBMESSAGING-741
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-742
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-742
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>    Affects Versions: 1.0.1.SP2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.2.CR1, 1.0.1.SP2
>
>         Attachments: jboss-messaging-client.jar, jboss-messaging.jar, jboss-remoting.jar
>
>
> PATCH NAME: 
>         JBMESSAGING-742
> PRODUCT NAME:
>         JBoss Messaging
> VERSION:
>         1.0.1.SP2        
> SHORT DESCRIPTION: 
>         This Patch will fix the reference to JMSDestination from Messages after a queue is restarted or redeployed, as well fixes introduced by Remoting Alpha4
> LONG DESCRIPTION: 
>         Prior to this fix, when a queue was restarted, you would get a null reference on message.getJMSDestination when receiving a message.
> MANUAL INSTALL INSTRUCTIONS:
>         Replace jboss-messaging.jar and jboss-remoting.jar under jboss-messaging.sar
>         Also replace eventual usages of jboss-messaging-client.jar.
> COMPATIBILITY: 
>         This patch is compatible with 1.0.1.SP2. No issues were introduced by this patch.
> CREATOR:
>         Clebert Suconic
> DATE:
>         Jan, 11th 2007

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:15:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-742) Update of
 JBossRemoting to Alpha4 and JBMESSAGING-741
In-Reply-To: <15501215.1168535007057.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7938341.1187133301365.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-742?page=all ]

Tim Fox resolved JBMESSAGING-742.
---------------------------------

    Resolution: Done

> Update of JBossRemoting to Alpha4 and JBMESSAGING-741
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-742
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-742
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>    Affects Versions: 1.0.1.SP2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.SP2, 1.0.2.CR1
>
>         Attachments: jboss-messaging-client.jar, jboss-messaging.jar, jboss-remoting.jar
>
>
> PATCH NAME: 
>         JBMESSAGING-742
> PRODUCT NAME:
>         JBoss Messaging
> VERSION:
>         1.0.1.SP2        
> SHORT DESCRIPTION: 
>         This Patch will fix the reference to JMSDestination from Messages after a queue is restarted or redeployed, as well fixes introduced by Remoting Alpha4
> LONG DESCRIPTION: 
>         Prior to this fix, when a queue was restarted, you would get a null reference on message.getJMSDestination when receiving a message.
> MANUAL INSTALL INSTRUCTIONS:
>         Replace jboss-messaging.jar and jboss-remoting.jar under jboss-messaging.sar
>         Also replace eventual usages of jboss-messaging-client.jar.
> COMPATIBILITY: 
>         This patch is compatible with 1.0.1.SP2. No issues were introduced by this patch.
> CREATOR:
>         Clebert Suconic
> DATE:
>         Jan, 11th 2007

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:17:14 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:17:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-26) Standalone
 Messaging configuration.
Message-ID: <3937073.1187133434263.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-26?page=all ]

Tim Fox updated JBMESSAGING-26:
-------------------------------

    Assignee:     (was: Alex Pinkin)

> Standalone Messaging configuration.
> -----------------------------------
>
>                 Key: JBMESSAGING-26
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-26
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>            Reporter: Ovidiu Feodorov
>             Fix For: 2.0.0 Beta 1
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> Prepare a stripped-down JBoss configuration that will be the "stand-alone" JBoss Messaging server. 
> Must have at least the JNDI server, Logging, Remoting and AOP support.
> We should provide a pre-packaged downloadable "standalone" config - users don't want to have to download and install the AS just so they can create a standalone installation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 19:17:14 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:17:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-693) Starting two
 node clusters
 simultaneously may end in failed messaging server node boot
In-Reply-To: <4904424.1166611478826.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11829548.1187133434550.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-693?page=all ]

Tim Fox closed JBMESSAGING-693.
-------------------------------

    Resolution: Done

> Starting two node clusters simultaneously may end in failed messaging server node boot
> --------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-693
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-693
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.CR1
>
>
> Tim Fox: 10:24:05,296 ERROR [DefaultClusteredPostOffice] Caught Exception in RequestHandler
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.addBindingFromCluster(DefaultClusteredPostOffice.java:597)
>         at org.jboss.messaging.core.plugin.postoffice.cluster.BindRequest.execute(BindRequest.java:55)
>         at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$PostOfficeRequestHandler.handle(DefaultClusteredPostOffice.java:2526)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:602)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:623)
>         at org.jgroups.blocks.RequestCorrelator.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 lists.jboss.org  Tue Aug 14 19:19:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Aug 2007 19:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-858)
 org.jboss.test.messaging.jms.bridge.ReconnectTest times out while run over
 HTTP
In-Reply-To: <21901867.1171955138087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17559075.1187133541210.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-858?page=all ]

Tim Fox closed JBMESSAGING-858.
-------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: Unscheduled)
       Resolution: Done
         Assignee: Tim Fox

> org.jboss.test.messaging.jms.bridge.ReconnectTest times out while run over HTTP
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-858
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-858
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> ReconnectTests actually pass for both bisocket and HTTP, but the cleanup fails for HTTP, causing the test to hang and timeout. 
> All individual tests have been modified to exit for HTTP. They need to be re-enabled, and the HTTP cleanup issue fixed.
> Search for JBMESSAGING-858 in the code and re-enable the 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 lists.jboss.org  Tue Aug 14 19:24:01 2007
From: jira-events at lists.jboss.org (Steven Holmes (JIRA))
Date: Tue, 14 Aug 2007 19:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6216566.1187133841814.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12372175 ] 
            
Steven Holmes commented on JBPORTAL-1626:
-----------------------------------------

Here is running on a Sun Solaris 10 server:

16:13:21,404 ERROR [ContentGetCommand] Cannot get content
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/wsp_node/acff7658-2ca1-4473-ae27-b96a3f0a634a, ca
ller=Thread[http-192.168.0.235-9080-1,5,jboss], lock=write owner=GlobalTransaction:<null>:5 (activeReaders=0, activeWriter=Thread[http-192.168.0.
235-9080-1,5,jboss], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
        at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.exists(JBossCachePersistenceManager.java:508)
        at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:906)
        at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:271)
        at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:179)
        at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:261)
        at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
        at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:461)
        at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:319)
        at org.apache.jackrabbit.core.PropertyImpl.getNode(PropertyImpl.java:656)
        at org.apache.jackrabbit.core.NodeImpl.getVersionHistory(NodeImpl.java:3148)
        at org.jboss.portal.cms.impl.jcr.command.ContentGetCommand.execute(ContentGetCommand.java:109)
        at org.jboss.portal.cms.impl.jcr.JCRCommandContext.execute(JCRCommandContext.java:75)
        at org.jboss.portal.cms.impl.jcr.command.FileGetCommand.execute(FileGetCommand.java:113)
        at org.jboss.portal.cms.impl.jcr.JCRCMS$1.invoke(JCRCMS.java:118)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.cms.impl.interceptors.ApprovalWorkflowInterceptor.invoke(ApprovalWorkflowInterceptor.java:116)
        at org.jboss.portal.cms.CMSInterceptor.invoke(CMSInterceptor.java:36)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.cms.impl.interceptors.ACLInterceptor.invoke(ACLInterceptor.java:248)
        at org.jboss.portal.cms.CMSInterceptor.invoke(CMSInterceptor.java:36)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.cms.impl.jcr.JCRCMS.execute(JCRCMS.java:630)
        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 $Proxy229.execute(Unknown Source)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:221)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSup
ported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java
:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke
$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:1
16)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke
$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericContentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(Tra
nsactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/wsp_node/acff7658-2ca1-4473-ae27-b96a3f0a634a, caller=Thread[http-
192.168.0.235-9080-1,5,jboss], lock=write owner=GlobalTransaction:<null>:5 (activeReaders=0, activeWriter=Thread[http-192.168.0.235-9080-1,5,jbos
s], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
        at org.jboss.cache.Node.acquire(Node.java:500)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:379)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:307)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:181)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:212)
        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.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:186)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:365)
        at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
        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:5863)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3627)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3608)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3595)
        at sun.reflect.GeneratedMethodAccessor320.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 $Proxy199.get(Unknown Source)
        at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.exists(JBossCachePersistenceManager.java:469)
        ... 270 more
Caused by: org.jboss.cache.lock.TimeoutException: read lock for /wsp_node/acff7658-2ca1-4473-ae27-b96a3f0a634a could not be acquired by Thread[ht
tp-192.168.0.235-9080-1,5,jboss] after 15000 ms. Locks: Read lock owners: []
Write lock owner: GlobalTransaction:<null>:5
, lock info: write owner=GlobalTransaction:<null>:5 (activeReaders=0, activeWriter=Thread[http-192.168.0.235-9080-1,5,jboss], waitingReaders=0, w
aitingWriters=0, waitingUpgrader=0)
        at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:262)
        at org.jboss.cache.Node.acquireReadLock(Node.java:512)
        at org.jboss.cache.Node.acquire(Node.java:474)
        ... 299 more
16:13:21,538 ERROR [org_jboss_portal_core_cms_ui_CMSPortlet] The portlet threw an exception
java.lang.NullPointerException
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:235)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSup
ported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java
:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke
$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:1
16)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke
$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericContentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(Tra
nsactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)
16:13:21,564 ERROR [DefaultPageControlPolicy] Rendering portlet window  produced an error
java.lang.NullPointerException
        at org.jboss.portal.core.cms.ui.CMSPortlet.doView(CMSPortlet.java:235)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
        at org.jboss.portal.core.cms.ui.CMSPortlet.doDispatch(CMSPortlet.java:313)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeRender(PortletContainerImpl.java:483)
        at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:405)
        at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(PortletContainerInvoker.java:86)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSup
ported$aop(TransactionInterceptor.java:86)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
        at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_N4547270787964792031.invokeNext(TransactionInterceptor
$invokeNotSupported_N4547270787964792031.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInterceptor.java)
        at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:56)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheInterceptor.java:58)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.portlet.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:62)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:47)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:55)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(PortletSessionSynchronizationInterceptor.java
:80)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:46)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.doCallback(ContextDispatcherInterceptor.java:89)
        at org.jboss.portal.web.jboss.JBossWebContext$InvokeNextCommand.execute(JBossWebContext.java:133)
        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:99)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
        at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
        at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
        at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
        at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:60)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:198)
        at org.jboss.portal.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:233)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.org$jboss$portal$core$impl$portlet$state$ProducerPortletInvoker$invoke
$aop(ProducerPortletInvoker.java:53)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker$invoke_N8654503705355129869.invokeNext(ProducerPortletInvoker$invoke_N
8654503705355129869.java)
        at org.jboss.portal.core.impl.portlet.state.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java)
        at org.jboss.portal.portlet.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:147)
        at org.jboss.portal.portlet.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:147)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$1.invoke(InstanceContainerImpl.java:98)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.portlet.management.PortletContainerManagementInterceptorImpl.invoke(PortletContainerManagementInterceptorImpl.java:58
)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSessionSynchronizationInterceptor.java:1
16)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityInterceptor.java:78)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:134)
        at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$invoke
$aop(InstanceContainerImpl.java:413)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl$invoke_N8654503705355129869.invokeNext(InstanceContainerImpl$invoke_N8
654503705355129869.java)
        at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.invoke(InstanceContainerImpl.java)
        at org.jboss.portal.core.impl.model.instance.AbstractInstance.invoke(AbstractInstance.java:231)
        at org.jboss.portal.core.impl.model.content.InternalContentProvider.renderWindow(InternalContentProvider.java:240)
        at org.jboss.portal.core.impl.model.content.generic.InternalGenericContentProvider.renderWindow(InternalGenericContentProvider.java:210)
        at org.jboss.portal.core.cms.content.InternalCMSContentProvider.renderWindow(InternalCMSContentProvider.java:105)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.execute(RenderWindowCommand.java:88)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.command.render.RenderWindowCommand.render(RenderWindowCommand.java:68)
        at org.jboss.portal.core.model.portal.command.render.RenderPageCommand.execute(RenderPageCommand.java:203)
        at org.jboss.portal.core.controller.ControllerCommand$1.invoke(ControllerCommand.java:68)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.aspects.controller.node.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:123)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ControlInterceptor.invoke(ControlInterceptor.java:57)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PageCustomizerInterceptor.invoke(PageCustomizerInterceptor.java:118)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:77)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.node.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:81)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.NavigationalStateInterceptor.invoke(NavigationalStateInterceptor.java:42)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.controller.ajax.AjaxInterceptor.invoke(AjaxInterceptor.java:51)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.controller.ResourceAcquisitionInterceptor.invoke(ResourceAcquisitionInterceptor.java:50)
        at org.jboss.portal.core.controller.ControllerInterceptor.invoke(ControllerInterceptor.java:40)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.core.controller.ControllerContext.execute(ControllerContext.java:128)
        at org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:74)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:79)
        at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:53)
        at org.jboss.portal.core.controller.handler.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:72)
        at org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:279)
        at org.jboss.portal.core.controller.Controller.processCommand(Controller.java:267)
        at org.jboss.portal.core.controller.Controller.handle(Controller.java:226)
        at org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
        at org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        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.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:245)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:84)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(Tra
nsactionInterceptor.java:49)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143
606530999904530.java)
        at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
        at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.server.aspects.LockInterceptor$InternalLock.invoke(LockInterceptor.java:70)
        at org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:131)
        at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
        at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
        at org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:380)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595)

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 20:06:01 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 14 Aug 2007 20:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1630) WindowState and
 Mode comparator severely broken
Message-ID: <22181787.1187136361049.JavaMail.jira@cloud.prod.atl2.jboss.com>

WindowState and Mode comparator severely broken
-----------------------------------------------

                 Key: JBPORTAL-1630
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1630
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.1 Final, 2.8 Final
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 Final


- not thread safe
- is using family for comparison instead of 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 lists.jboss.org  Tue Aug 14 20:16:01 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 14 Aug 2007 20:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1623) Create "Admin"
 icon for the different themes for the new admin portlet mode
In-Reply-To: <19138744.1186510029362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15462499.1187136961203.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1623?page=comments#action_12372177 ] 
            
Julien Viet commented on JBPORTAL-1623:
---------------------------------------

Done for renaissance theme

> Create "Admin" icon for the different themes for the new admin portlet mode
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1623
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1623
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.6.3 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 lists.jboss.org  Tue Aug 14 20:16:01 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 14 Aug 2007 20:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1630) WindowState and
 Mode comparator severely broken
In-Reply-To: <22181787.1187136361049.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29106641.1187136961322.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1630?page=all ]

Julien Viet resolved JBPORTAL-1630.
-----------------------------------

    Resolution: Done

> WindowState and Mode comparator severely broken
> -----------------------------------------------
>
>                 Key: JBPORTAL-1630
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1630
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> - not thread safe
> - is using family for comparison instead of 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 lists.jboss.org  Tue Aug 14 20:45:12 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 20:45:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1084) Provide case
 insentive
 completions in eth DRL Editor for MVEL and Java completions
Message-ID: <24431326.1187138712419.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide case insentive completions in eth DRL Editor for MVEL and Java completions 
-----------------------------------------------------------------------------------

                 Key: JBRULES-1084
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1084
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Philippe Ombredanne
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: 4.0.1


You do not get the same completions when typing a lower case or upper case prefix.
Completaions should be offered for all the lower or uppercase prefix

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 20:49:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 20:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1084) Provide case
 insentive
 completions in eth DRL Editor for MVEL and Java completions
In-Reply-To: <24431326.1187138712419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3684230.1187138941129.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1084?page=all ]

Philippe Ombredanne resolved JBRULES-1084.
------------------------------------------

    Resolution: Done

Fixed.
This was a bug reported by fmeyer

> Provide case insentive completions in eth DRL Editor for MVEL and Java completions 
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-1084
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1084
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Philippe Ombredanne
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> You do not get the same completions when typing a lower case or upper case prefix.
> Completaions should be offered for all the lower or uppercase prefix

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 20:58:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 20:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1080) Modify (var)
 added to Eclipse code completion for mvel
In-Reply-To: <19252810.1187049901307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13129382.1187139481131.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1080?page=all ]

Philippe Ombredanne resolved JBRULES-1080.
------------------------------------------

    Resolution: Done
      Assignee: Mark Proctor  (was: Philippe Ombredanne)

Fixed. Not applying macro processing to massaged mvel xpre4ssion was the issue

> Modify (var) added to Eclipse code completion for mvel
> ------------------------------------------------------
>
>                 Key: JBRULES-1080
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1080
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Mark Proctor
>            Priority: Minor
>         Attachments: mvel.png
>
>
> Reported by Mark: 
> I've found a weird one with context assist, some how its adding "modify ( var )" to the list of context completions, but it only does that if you've already added the line to the consequence. See modify( game ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 14 21:00:01 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Tue, 14 Aug 2007 21:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1084) Provide case
 insentive
 completions in eth DRL Editor for MVEL and Java completions
In-Reply-To: <24431326.1187138712419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24623275.1187139601177.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1084?page=all ]

Philippe Ombredanne reassigned JBRULES-1084:
--------------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

for your review

> Provide case insentive completions in eth DRL Editor for MVEL and Java completions 
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-1084
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1084
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Philippe Ombredanne
>         Assigned To: Fernando Meyer
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> You do not get the same completions when typing a lower case or upper case prefix.
> Completaions should be offered for all the lower or uppercase prefix

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 02:19:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 15 Aug 2007 02:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-449)
 maven-jbossaop-plugin cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14638977.1187158741186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Stale Pedersen resolved JBAOP-449.
----------------------------------

    Resolution: Done

fixed bug in svn

> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Wed Aug 15 02:35:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 15 Aug 2007 02:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24479531.1187159701742.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-453?page=all ]

Stale Pedersen resolved JBAOP-453.
----------------------------------

    Resolution: Done

with input/help from paul gier i've changed how we build the classpath, from using project.artifacts, to plugin.artifacts.
the dependencies within the pom will stay as they are atm. this will make it as easy as possible for the end user to aopc with maven.
the plan is that each new release of aop, will have a similar maven-plugin release. - and they will have the same version to prevent confusion.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug 15 02:35:02 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Wed, 15 Aug 2007 02:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14812457.1187159702026.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372199 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

- we will document this on the wiki and the bundled documentation when we release 2.0

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Wed Aug 15 04:16:01 2007
From: jira-events at lists.jboss.org (John Ruud (JIRA))
Date: Wed, 15 Aug 2007 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-77) Need a way to
 initialize palette objects in GD 3.1
In-Reply-To: <32064405.1178744992373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10910584.1187165761466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-77?page=comments#action_12372213 ] 
            
John Ruud commented on GPD-77:
------------------------------

Thanks Koen, *now* I understand (and it seems to work!)

John

> Need a way to initialize palette objects in GD 3.1
> --------------------------------------------------
>
>                 Key: GPD-77
>                 URL: http://jira.jboss.com/jira/browse/GPD-77
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.alpha4
>            Reporter: John Ruud
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.beta2
>
>         Attachments: GPD-77.patch
>
>
> For example, whenever an 'EndState' node is added to the diagram, I need for it to be initialized with a particular event, action, and some action properties. I have made some minor changes to the GD code in order to support this, as described in the following post: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108175
> It would be very helpful if these changes, or similar functionality, can be included in 3.1, as I wouldn't need to keep maintaining my own custom version of the GD feature. I'd be happy to post a patch, if that helps (while my changes are very simple, as described in the 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 lists.jboss.org  Wed Aug 15 04:34:01 2007
From: jira-events at lists.jboss.org (stefan lotties (JIRA))
Date: Wed, 15 Aug 2007 04:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4609) Original
 SevletResponse or
 wrapped original ServletResponse not passed to RequestDispatcher in
 violation of SRV.8.2 and SRV.14.2.5.1
Message-ID: <14152110.1187166841533.JavaMail.jira@cloud.prod.atl2.jboss.com>

Original SevletResponse or wrapped original ServletResponse not passed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-4609
                 URL: http://jira.jboss.com/jira/browse/JBAS-4609
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.0.GA
         Environment: RHeL
            Reporter: stefan lotties


Sometimes in the log the following stacktrace appears while someone is surfing in an application:
2007-08-09 12:10:01,834 [http-0.0.0.0-8080-1] ERROR org.apache.catalina.core.ContainerBase.[jboss.we
b].[localhost].[/webadmin].[action] - Servlet.service() for servlet action threw exception
javax.servlet.ServletException: Original SevletResponse or wrapped original ServletResponse not pass
ed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
        at org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.jav
a:1018)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:329)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
        at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056)
        at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261)
        at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcesso
r.java:237)
        at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.
java:300)
        at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231)
        at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
        at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
        at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:271)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:
469)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
        at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.
java:316)
        at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:2
44)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:
156)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
va:580)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:595) 

I debugged as far as I could and noticed that the http-request returns the host the jboss runs on when calling HttpServletRequest.getRemoteHost() and has "HEAD" as method. It can't be reproduced since it seems to be kinda random (doing the same action twice or more often does not end in this exception). Also the requested-URIs are different. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 04:34:02 2007
From: jira-events at lists.jboss.org (stefan lotties (JIRA))
Date: Wed, 15 Aug 2007 04:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4609) Original
 SevletResponse or
 wrapped original ServletResponse not passed to RequestDispatcher in
 violation of SRV.8.2 and SRV.14.2.5.1
In-Reply-To: <14152110.1187166841533.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29630881.1187166842066.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4609?page=comments#action_12372220 ] 
            
stefan lotties commented on JBAS-4609:
--------------------------------------

btw: This "problem" does not affect anything. It's just irritating for our customers. Also this never appeared with jboss 4.0.5 GA.

> Original SevletResponse or wrapped original ServletResponse not passed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4609
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4609
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: RHeL
>            Reporter: stefan lotties
>
> Sometimes in the log the following stacktrace appears while someone is surfing in an application:
> 2007-08-09 12:10:01,834 [http-0.0.0.0-8080-1] ERROR org.apache.catalina.core.ContainerBase.[jboss.we
> b].[localhost].[/webadmin].[action] - Servlet.service() for servlet action threw exception
> javax.servlet.ServletException: Original SevletResponse or wrapped original ServletResponse not pass
> ed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
>         at org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.jav
> a:1018)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:329)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056)
>         at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261)
>         at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcesso
> r.java:237)
>         at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.
> java:300)
>         at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231)
>         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
>         at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
>         at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:271)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
> ava:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
>         at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:
> 469)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.
> java:316)
>         at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:2
> 44)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:
> 156)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
> va:580)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595) 
> I debugged as far as I could and noticed that the http-request returns the host the jboss runs on when calling HttpServletRequest.getRemoteHost() and has "HEAD" as method. It can't be reproduced since it seems to be kinda random (doing the same action twice or more often does not end in this exception). Also the requested-URIs are different. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 06:01:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 15 Aug 2007 06:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-81) Add support for
 reconnecting transitions
In-Reply-To: <898355.1178879092359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31705722.1187172061237.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-81?page=comments#action_12372232 ] 
            
Ronald van Kuijk commented on GPD-81:
-------------------------------------

YEAAAAAAHHHHHHHH WAY TO GO.....

I have to admit... the designer is getting better by the month/week... I regulary check everything out, build it and try it....... 

> Add support for reconnecting transitions
> ----------------------------------------
>
>                 Key: GPD-81
>                 URL: http://jira.jboss.com/jira/browse/GPD-81
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>         Environment: Clean eclipse 3.2.2 and gpd 3.1alpha4
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> Not being able to reconnect transitions graphically from e.g. node a to node b is still a big omission for the gpd to be used by 'grey suites' as well as 'jeans and t-shirts', at least within our company. I thought there was a long standing issue for this, but I cannot find it. 
> If someone could point me to a place to start looking into this, I'd be happy to try to implement this (but it will be the only gpd thing I 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 lists.jboss.org  Wed Aug 15 06:01:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 06:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4600) Rename JBossMQ
 variables from jboss-messaging to jboss.messaging-mq.lib
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21413685.1187172061352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4600?page=all ]

Dimitris Andreadis updated JBAS-4600:
-------------------------------------

    Summary: Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib  (was: Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib and add jboss-messaging into build-thirdparty)

> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib
> -----------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 06:58:00 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 06:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1143) Migrate
 repository from CVS to SVN
In-Reply-To: <5716848.1184844227121.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7249329.1187175481001.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1143?page=all ]

Manik Surtani resolved JBCACHE-1143.
------------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Migrate repository from CVS to SVN
> ----------------------------------
>
>                 Key: JBCACHE-1143
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1143
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:00:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1144) Update build
 system to use Maven2 rather than Ant
In-Reply-To: <7905246.1184844227204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17334173.1187175601052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1144?page=all ]

Manik Surtani resolved JBCACHE-1144.
------------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Update build system to use Maven2 rather than Ant
> -------------------------------------------------
>
>                 Key: JBCACHE-1144
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1144
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:00:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-1147) Document changes
In-Reply-To: <11638383.1184844347023.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28306007.1187175601140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1147?page=all ]

Manik Surtani resolved JBCACHE-1147.
------------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Document changes
> ----------------
>
>                 Key: JBCACHE-1147
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1147
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:12:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-1145) Update test
 suite to use TestNG
In-Reply-To: <32594581.1184844227288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19646453.1187176321234.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1145?page=all ]

Manik Surtani reassigned JBCACHE-1145:
--------------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> Update test suite to use TestNG
> -------------------------------
>
>                 Key: JBCACHE-1145
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1145
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:12:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1146) Parameterise
 tests for various permutations
In-Reply-To: <6430365.1184844227374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18795607.1187176321349.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1146?page=all ]

Manik Surtani updated JBCACHE-1146:
-----------------------------------

    Assignee: Jason T. Greene  (was: Manik Surtani)

> Parameterise tests for various permutations
> -------------------------------------------
>
>                 Key: JBCACHE-1146
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1146
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:14:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1145) Update test suite
 to use TestNG
In-Reply-To: <32594581.1184844227288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4797663.1187176441144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1145?page=all ]

Manik Surtani updated JBCACHE-1145:
-----------------------------------

    Fix Version/s: 2.1.0.GA

> Update test suite to use TestNG
> -------------------------------
>
>                 Key: JBCACHE-1145
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1145
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:14:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 15 Aug 2007 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1146) Parameterise
 tests for various permutations
In-Reply-To: <6430365.1184844227374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22779565.1187176441268.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1146?page=all ]

Manik Surtani updated JBCACHE-1146:
-----------------------------------

    Fix Version/s: 2.1.0.GA

> Parameterise tests for various permutations
> -------------------------------------------
>
>                 Key: JBCACHE-1146
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1146
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Jason T. Greene
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:30:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 07:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-35) enhancement drawing
	transitions
In-Reply-To: <9729958.1168962532978.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9672616.1187177401067.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-35?page=comments#action_12372242 ] 
            
Koen Aers commented on GPD-35:
------------------------------

I'll certainly have a look at this, but my GEF knowledge is currently not at the point that I know directly how I should attack this. It will need some investigation, if possible at all.
If anyone knows of an example of this with GEF, please direct me to it...

Regards,
Koen

> enhancement drawing transitions
> -------------------------------
>
>                 Key: GPD-35
>                 URL: http://jira.jboss.com/jira/browse/GPD-35
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>
> When the mousepointer is in the outer area of a node/state/task/.... but within it's boundaries, it should be possible to draw a transition. This is makes using the gpd a lot faster (not switching in the toolbar)
> Maybe it should only be in the 'middle areas' of top, bottom, left and right and not the corners

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:41:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 07:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-139) Cannot add tasks to
	the task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15474077.1187178061148.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-139?page=comments#action_12372243 ] 
            
Koen Aers commented on GPD-139:
-------------------------------

Hm, I am afraid I could not reproduce this. Or maybe I fixed this already without knowing. Can anyone verify if the problem still exists?

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 07:47:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 15 Aug 2007 07:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1030) Implement EE
 8.2.1 section 2 functionality
Message-ID: <31360626.1187178421124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement EE 8.2.1 section 2 functionality
------------------------------------------

                 Key: EJBTHREE-1030
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1030
             Project: EJB 3.0
          Issue Type: Sub-task
            Reporter: Carlo de Wolf
             Fix For: EJB 3.0 RC11 - 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 lists.jboss.org  Wed Aug 15 07:49:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 15 Aug 2007 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1031) only 4 equality
 checks are made for fact
In-Reply-To: <9998356.1185475797431.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10095913.1187178541189.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1031?page=all ]

Edson Tirelli updated JBRULES-1031:
-----------------------------------

    Summary: only 4 equality checks are made for fact  (was: using Not only allows me to use 4 equality checks for fact)

> only 4 equality checks are made for fact
> ----------------------------------------
>
>                 Key: JBRULES-1031
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1031
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Fedora 7, JDK 1.5.0_12
>            Reporter: Eric Miles
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: drools-not-fact-test.tar.gz
>
>
> I have a single rule in my test bed as such:
> rule "5th Item Not Test"
>     
>     when
>         $first : FirstClass($i1 : item1, $i2 : item2, $i3 : item3, $i4 : item4, $i5 : item5)
>         not SecondClass(item1 == $i1, item2 == $i2, item3 == $i3, item4 == $i4, item5 == $i5)
>     then
>         System.out.println("NOT test matched");
>        
> end
> In the not SecondClass() section of the test, the last equality checks always fail, no matter what it is.  I can switch the order around of the checks, no matter what the last one is, it causes THEN clause to not fire, even when I am absolutely positive there is not a match.  (I can remove the not and the equality works fine).  Is there a limit on the number of equality tests I can do with a not?  It seems as though it is 4.  I have attached a test case that can reproduce this (it is different from my project's code, but I have been able to reproduce this in multiple projects).  It is a maven Eclipse project and includes a junit with some minor instructions.  I have created a rule that will fire as the opposite of the rule I'm trying to test and it prints out the values to the console.  You can see in the console that the values are not equal, although the rule fired that they were.
> If these instructions do not make sense, please email me. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 08:25:01 2007
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Wed, 15 Aug 2007 08:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4606) Hypersonic server
 mode TCP socket problem
In-Reply-To: <5093937.1187090041430.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23419749.1187180701536.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4606?page=comments#action_12372259 ] 
            
Martin Vecera commented on JBAS-4606:
-------------------------------------

I discovered following error in server.log today.
It seems like I have to wait 5 minutes after JBossAS shutdown before the driver can work again. But no Java process is left (ps aux and jps reports nothing interesting). I'm not sure if it is the same problem as I experienced yesterday :-( No 'localhost' tricks are working except for the 5 minute break.

2007-08-15 14:45:11,245 DEBUG [org.jboss.system.ServiceController] starting service jboss.ejb:service=EJBTimerService,persistencePolicy=database
2007-08-15 14:45:11,245 DEBUG [org.jboss.ejb.txtimer.DatabasePersistencePolicy] Starting jboss.ejb:service=EJBTimerService,persistencePolicy=database
2007-08-15 14:45:11,259 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: run() entered
2007-08-15 14:45:11,259 INFO  [STDOUT] [Server at 862041]: Initiating startup sequence...
2007-08-15 14:45:11,259 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.database=/var/lib/jbossas/server/default/data/hypersonic/default
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.tls=false
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.port=1701
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.trace=true
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.database.0=/var/lib/jbossas/server/default/data/hypersonic/default
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.restart_on_shutdown=false
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.no_system_exit=true
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.silent=false
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.default_page=index.html
2007-08-15 14:45:11,260 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.address=localhost
2007-08-15 14:45:11,261 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.dbname.0=
2007-08-15 14:45:11,261 INFO  [STDOUT] [Server at 862041]: [Thread[HSQLDB Server @862041,5,jboss]]: server.root=.
2007-08-15 14:45:11,331 INFO  [STDOUT] DriverManager.getDriver("jdbc:hsqldb:hsql://localhost:1701")
2007-08-15 14:45:11,331 INFO  [STDOUT] DriverManager.initialize: jdbc.drivers = null
2007-08-15 14:45:11,331 INFO  [STDOUT] JDBC DriverManager initialized
2007-08-15 14:45:11,331 INFO  [STDOUT] getDriver: no suitable driver
2007-08-15 14:45:11,336 INFO  [STDOUT] java.sql.SQLException: No suitable driver
	at java.sql.DriverManager.getDriver(DriverManager.java:243)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.isDriverLoadedForURL(LocalManagedConnectionFactory.java:300)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getDriver(LocalManagedConnectionFactory.java:264)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:170)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
	at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
	at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
	at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
	at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
	at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
	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 org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	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 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 $Proxy42.start(Unknown Source)
	at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
	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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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.Ma
2007-08-15 14:45:11,336 INFO  [STDOUT] inDeployer.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:508)
	at java.lang.Thread.run(Thread.java:595)
SQLException: SQLState(08001)
2007-08-15 14:45:11,339 INFO  [STDOUT] registerDriver: driver[className=org.hsqldb.jdbcDriver,org.hsqldb.jdbcDriver at 11cccce]
2007-08-15 14:45:11,339 INFO  [STDOUT] DriverManager.getDriver("jdbc:hsqldb:hsql://localhost:1701")
2007-08-15 14:45:11,339 INFO  [STDOUT]     trying driver[className=org.hsqldb.jdbcDriver,org.hsqldb.jdbcDriver at 11cccce]
2007-08-15 14:45:11,339 INFO  [STDOUT] getDriver returning driver[className=org.hsqldb.jdbcDriver,org.hsqldb.jdbcDriver at 11cccce]
2007-08-15 14:45:11,388 INFO  [STDOUT] SQLException: SQLState(IM001) vendor code(-20)
2007-08-15 14:45:11,392 INFO  [STDOUT] java.sql.SQLException: This function is not supported
	at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
	at org.hsqldb.jdbc.Util.<clinit>(Unknown Source)
	at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
	at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
	at org.hsqldb.jdbcDriver.connect(Unknown Source)
	at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
	at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
	at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
	at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
	at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
	at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
	at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
	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 org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	at org.jboss.system.ServiceController.start(ServiceController.java:435)
	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 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 $Proxy42.start(Unknown Source)
	at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
	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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:1
2007-08-15 14:45:11,392 INFO  [STDOUT] 025)
	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:508)
	at java.lang.Thread.run(Thread.java:595)
SQLException: SQLState(08000) vendor code(-80)
2007-08-15 14:45:11,401 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.parentTraceEnabled=true
2007-08-15 14:45:11,401 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.nestedTraceEnabled=false
2007-08-15 14:45:11,401 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true
2007-08-15 14:45:11,398 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)


> Hypersonic server mode TCP socket problem
> -----------------------------------------
>
>                 Key: JBAS-4606
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4606
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: Sun JVM, x86_64&i686, RHEL5, JBossAS conf. "default", running as service jbossas.
>            Reporter: Martin Vecera
>         Assigned To: Dimitris Andreadis
>
> I wanted to deploy Duke's bank J2EE example. This requires HSQLDB in server mode. The server/deploy/hsqldb-ds.xml is well prepared for switching HSQLDB to server mode, so I did it. This XML file uses ${jboss.bind.address} property to determine HSQLDB binding address.
> I was running JBossAS with 'service jbossas start'. In /etc/sysconfig/jbossas I had JBOSS_IP=127.0.0.1.
> I got the following error:
> 2007-08-14 13:27:30,715 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
> org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:179)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
>         at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
>         at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
>         at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
>         at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
>         at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
>         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 org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         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 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 $Proxy42.start(Unknown Source)
>         at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
>         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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:508)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.sql.SQLException: socket creation error
>         at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
>         at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
>         at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
>         at org.hsqldb.jdbcDriver.connect(Unknown Source)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
>         ... 122 more
> When I replaced the {$jboss.bind.address} (both occurences in hsqldb-ds.xml) with 'localhost' everything was OK.
> So I tried to replace it with 127.0.0.1 and got the same error.
> Then I tried to put the ${jboss.bind.address} property back and changed JBOSS_IP in /etc/sysconfig/jbossas to 'localhost'.
> Well, everything was working then.
> So I returned JBOSS_IP=127.0.0.1 back and voila - everything is OK!!!
> I tried it twice on two different machines. Once I used JBOSS_IP=localhost I was able to use any of the previously mentioned configuration and it was working. VERY STRANGE! After each change I restarted JBossAS completely.
> I tried nslookup at the beginning to see if it is bound corectly:
> [root at xen61 deploy]# nslookup 127.0.0.1
> Server:         10.34.32.125
> Address:        10.34.32.125#53
> 1.0.0.127.in-addr.arpa  name = localhost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 08:36:01 2007
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Wed, 15 Aug 2007 08:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-995) CLONE -concurrent job
 acquirement fails
In-Reply-To: <29948611.1182451552483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3454275.1187181361596.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-995?page=all ]

Tom Baeyens closed JBPM-995.
----------------------------

    Fix Version/s: jBPM jPDL 3.2.2
       Resolution: Done

The static synchronization was added on the JobExecutor object.

Furthermore, the logging of optimistic locking failures is made configurable.  This is what was added to the user guide:

6.4. Logging of optimistic concurrency exceptions
When running in a cluster, jBPM synchronizes on the database. By default with optimistic locking. This means that each operation is performed in a transaction. And if at the end a collision is detected, then the transaction is rolled back and has to be handled. E.g. by a retry. So optimistic locking exceptions are usually part of the normal operation. Therefor, by default, the org.hibernate.StateObjectStateExceptions the that hibernate throws in that case are not logged with error and a stack trace, but instead a simple info message 'optimistic locking failed' is displayed. 

Hibernate itself will log the StateObjectStateException including a stack trace. If you want to get rid of these stack traces, put the level of org.hibernate.event.def.AbstractFlushingEventListener to FATAL. If you use log4j following line of configuration can be used for that: 

log4j.logger.org.hibernate.event.def.AbstractFlushingEventListener=FATAL

If you want to enable logging of the jBPM stack traces, add the following line to your jbpm.cfg.xml: 

<boolean name="jbpm.hide.stale.object.exceptions" value="false" />


> CLONE -concurrent job acquirement fails
> ---------------------------------------
>
>                 Key: JBPM-995
>                 URL: http://jira.jboss.com/jira/browse/JBPM-995
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>            Reporter: Edward Staub
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>
> when more than 1 job executor thread is configured and concurrent async nodes are to be executed, it results in hibernate exceptions.
> reason: job acquirement is not synchronized well, resulting in multiple threads trying to work on the same job.
> In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been closed.  So I cloned it here..  let me know if that was incorrect process.  
> The problem was easy to reproduce, and was easy to predict in the first place.  Alex's fix (sychronize on a static class member around acquireJobs()) works for me as well.  It probably trivially improves performance, by avoiding aborted acquire attempts.
> As noted in JBPM-974, it only causes an erroneous error message being emitted - the code operates correctly.  It also makes debugging other race conditions much more difficult by injecting a lot of noise - they usually show up as stale objects as well.
> I believe the reason the trace is dumped to the log is because it's dumped at ERROR level before it even gets to JBPM, in org.hibernate.event.def.AbstractFlushingEventListener.performExecutions.  So the "catch (StaleStateException e)" doesn't suppress it - the horse has left the barn, the train has left the station, the s--t has already hit the fan - pick your favorite metaphor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 08:47:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 08:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1628) Portal bridge
	upgrade
In-Reply-To: <17053523.1187016541409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12758206.1187182021831.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1628?page=all ]

Thomas Heute resolved JBPORTAL-1628.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

> Portal bridge upgrade
> ---------------------
>
>                 Key: JBPORTAL-1628
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1628
>             Project: JBoss Portal
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 SP1
>            Reporter: Rakesh Ajmera
>         Assigned To: Thomas Heute
>             Fix For: 2.4.2 Final, 2.6.2 Final, 2.8 Final
>
>
> There is a new version of portal-bridge available 1.0.3(http://portals.apache.org/bridges/download.html). What's the plan of upgrading jboss portal to the latest version of portal bridge?
> We need the bug fixes available in this 1.0.3 release, but it doesn't work with the jboss's portal-bridge-lib.jar that is packaged with jboss portal.   We are using Struts bridge, that is dependent on the portals-bridges-common.jar, which in turn works with JBoss's potal-bridge-lib.jar. I upgraded the portal-bridges-common.jar with the latest version, but it didn't work with portal-bridge-lib.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 lists.jboss.org  Wed Aug 15 09:17:01 2007
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Wed, 15 Aug 2007 09:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-394)
 jboss/jboss-deployers/2.0.0.Beta
Message-ID: <837463.1187183821693.JavaMail.jira@cloud.prod.atl2.jboss.com>

jboss/jboss-deployers/2.0.0.Beta
--------------------------------

                 Key: JBBUILD-394
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-394
             Project: JBoss Build System
          Issue Type: Bug
          Components: Maven
            Reporter: Pete Muir
         Assigned To: Paul Gier
            Priority: Minor


jboss-deployers-2.0.0.Beta missing jar (pom is present).



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:27:14 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:27:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1498) Add Support for
 Internet Explorer's Conditional Comments
In-Reply-To: <21678833.1182478672108.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5230807.1187184434820.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1498?page=all ]

Thomas Heute resolved JBPORTAL-1498.
------------------------------------

    Fix Version/s:     (was: 2.8 Final)
                       (was: 2.6.2 Final)
       Resolution: Won't Fix
         Assignee: Thomas Heute  (was: Julien Viet)

So actually it should be something more generic that allows to define a different stylesheet for different User-Agents.

I close this case as "Won't fix" and open a new one with the more generic idea.

> Add Support for Internet Explorer's Conditional Comments
> --------------------------------------------------------
>
>                 Key: JBPORTAL-1498
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1498
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: All
>            Reporter: Andy Pemberton
>         Assigned To: Thomas Heute
>
> Currently, JBoss Portal's theme and layout architecture relies on XML deployment descriptors for several objects.  For example, the portal-theme.xml is used to create themes (javascript and css) that will be applied to layouts.
> The request I have is this: given the XML deployment descriptors, add in support for Internet Explorer's Conditional Comment system. 
> Conditional Comments have been a feature of IE since IE5. Basically, Conditional Comments are specially formatted HTML comments that allow web developers to target specific markup to Internet Explorer. Typically, Conditional Comments are used to import specific Cascading Style Sheets (CSS) to HTML pages to handle IE-specific CSS defects. 
> Currently, the lack of support for Conditional Comments is caused by the fact that Conditional Comments rely on XHTML-based comments, which are thus filtered out at the portal-theme.xml level. I considered adding this request as a defect, but decided against it as not reading in comments in an XML deployment descriptor is quite logical, and of course - IE's conditional comment system (though useful) is counter-intuitive. 
> Reference:
>  - http://msdn2.microsoft.com/en-us/library/ms537512.aspx

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:31:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1631) Allow different
 stylesheets for different user-agents
Message-ID: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow different stylesheets for different user-agents
-----------------------------------------------------

                 Key: JBPORTAL-1631
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Theme
            Reporter: Thomas Heute
         Assigned To: Julien Viet
             Fix For: 2.8 Final


It should be possible to define several stylesheets for a theme that would be applied for different user-agents.

Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:37:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1300) Default a
 portlet window to maximized.
In-Reply-To: <24092633.1173097870945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12374215.1187185021912.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1300?page=all ]

Thomas Heute updated JBPORTAL-1300:
-----------------------------------

    Fix Version/s: 2.8 Final

> Default a portlet window to maximized.
> --------------------------------------
>
>                 Key: JBPORTAL-1300
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1300
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: David Roberts
>            Priority: Optional
>             Fix For: 2.8 Final
>
>
> When adding portlets, it would be nice if there were an option where the portlet window could start out MAXIMIZED, so the entire portlet fills the screen nicely without the users having to click the maximize button. Eg. this would be very helpful when using the IFrame Portlet, so the URL being referenced fits the entire screen, and doesn't mess up the original layout of the referenced page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:44:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-206) Check that
 required fields are filled before logging in a user
Message-ID: <15991797.1187185441605.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-206?page=all ]

Thomas Heute updated JBPORTAL-206:
----------------------------------

    Fix Version/s: 2.8 Final

> Check that required fields are filled before logging in a user
> --------------------------------------------------------------
>
>                 Key: JBPORTAL-206
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-206
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0.1 Final
>            Reporter: Thomas Heute
>             Fix For: 2.8 Final
>
>
> Making sure to check that a user filled all required fields before letting him logging-in. Otherwise it should display a form with non-filled entries.
> This is useful when we add a new field in the registration form.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 09:46:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 09:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-1148) SEAM / JSF /
 Portlet: Compatibility problem
In-Reply-To: <33157558.1164905095910.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12800845.1187185561512.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1148?page=all ]

Thomas Heute closed JBPORTAL-1148.
----------------------------------

    Resolution: Won't Fix
      Assignee: Thomas Heute  (was: Julien Viet)

>From the JBSEAM-347 that it was a non-issue

> SEAM / JSF / Portlet: Compatibility problem
> -------------------------------------------
>
>                 Key: JBPORTAL-1148
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1148
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6.CR1
>         Environment: Windows XP
> MyFaces 1.1.5
> SEAM 1.0.1
>            Reporter: JP Barbe
>         Assigned To: Thomas Heute
>
> When I use a seam tag into a jsf page, I have the following exception (You can see config files after the exception):
> 2006-11-30 17:20:57,934 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/seam-desk]] No active conversation context
> 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.Component.getInstance(Component.java:1230)
> 	at org.jboss.seam.contexts.Lifecycle.resumeConversation(Lifecycle.java:328)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.restoreAnyConversationContext(AbstractSeamPhaseListener.java:42)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.beforePhase(SeamPortletPhaseListener.java:51)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.beforePhase(SeamExtendedManagedPersistencePortletPhaseListener.java:37)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.informPhaseListenersBefore(LifecycleImpl.java:520)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:342)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:396)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
> 	at com.eads.desk.core.portlet.DeskAccessPortlet.doView(DeskAccessPortlet.java:30)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
> #### Here is the faces-config.xml file:
> <faces-config>
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> 	
> 	
> 	<navigation-rule>
> 		<from-view-id>/view/deskAccess.jsp</from-view-id>
> 		<navigation-case>
> 			<from-outcome>trManager</from-outcome>
> 			<to-view-id>/view/viewTRManager.jsp</to-view-id>
> 			<redirect />
> 		</navigation-case>	
> 	</navigation-rule>
>     
>     <navigation-rule>
>     	<navigation-case>
>     		<from-action>#{pooledTask.assignToCurrentActor}</from-action>
>     		<from-outcome>taskAssignedToActor</from-outcome>
>     		<to-view-id>/view/viewTRManager.jsp</to-view-id>
>     	</navigation-case>
>     </navigation-rule>
> 	
> </faces-config>
> #### web.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <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">
>     <!-- Seam -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> </web-app>
> ###
> I have seen an issue (Key: JBSEAM-347) but I don't anderstand the solution proposed or if a solution exists !
> (http://jira.jboss.org/jira/browse/JBSEAM-347)
> Thanks.
> JP.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:03:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 15 Aug 2007 10:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-995) CLONE -concurrent
 job acquirement fails
In-Reply-To: <29948611.1182451552483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17822371.1187186581563.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-995?page=comments#action_12372284 ] 
            
Ronald van Kuijk commented on JBPM-995:
---------------------------------------

cool... only a strange name for a property.... jbpm.hide...... why not CamelCasing? (me nitpicking :-) )

> CLONE -concurrent job acquirement fails
> ---------------------------------------
>
>                 Key: JBPM-995
>                 URL: http://jira.jboss.com/jira/browse/JBPM-995
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>            Reporter: Edward Staub
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>
> when more than 1 job executor thread is configured and concurrent async nodes are to be executed, it results in hibernate exceptions.
> reason: job acquirement is not synchronized well, resulting in multiple threads trying to work on the same job.
> In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been closed.  So I cloned it here..  let me know if that was incorrect process.  
> The problem was easy to reproduce, and was easy to predict in the first place.  Alex's fix (sychronize on a static class member around acquireJobs()) works for me as well.  It probably trivially improves performance, by avoiding aborted acquire attempts.
> As noted in JBPM-974, it only causes an erroneous error message being emitted - the code operates correctly.  It also makes debugging other race conditions much more difficult by injecting a lot of noise - they usually show up as stale objects as well.
> I believe the reason the trace is dumped to the log is because it's dumped at ERROR level before it even gets to JBPM, in org.hibernate.event.def.AbstractFlushingEventListener.performExecutions.  So the "catch (StaleStateException e)" doesn't suppress it - the horse has left the barn, the train has left the station, the s--t has already hit the fan - pick your favorite metaphor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:15:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 15 Aug 2007 10:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-139) Cannot add tasks to
	the task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3581063.1187187301209.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-139?page=comments#action_12372286 ] 
            
Ronald van Kuijk commented on GPD-139:
--------------------------------------

I will... just synced the latest with cvs.... give me 1 hour 

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:22:23 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 10:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4600) Rename JBossMQ
 variables from jboss-messaging to jboss.messaging-mq.lib
In-Reply-To: <10449640.1186689003223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17577957.1187187743447.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4600?page=all ]

Dimitris Andreadis closed JBAS-4600.
------------------------------------

    Resolution: Done

I've left in the renaming of mq variable and reverted the introduction of jboss messaging


> Rename JBossMQ variables from jboss-messaging to jboss.messaging-mq.lib
> -----------------------------------------------------------------------
>
>                 Key: JBAS-4600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4600
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.2.2.GA
>
>
> It's not possible to add jboss-messaging into thirdparty as buildmagic/modules/xml defines it as a variable name called jboss-messaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:43:06 2007
From: jira-events at lists.jboss.org (Eric Brown (JIRA))
Date: Wed, 15 Aug 2007 10:43:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1143) Migrate
 repository from CVS to SVN
In-Reply-To: <5716848.1184844227121.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7789404.1187188986219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1143?page=all ]

Eric Brown updated JBCACHE-1143:
--------------------------------

    Help Desk Ticket Reference: https://rt.corp.redhat.com/rt3/Ticket/Display.html?id=414277

> Migrate repository from CVS to SVN
> ----------------------------------
>
>                 Key: JBCACHE-1143
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1143
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 10:45:01 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 15 Aug 2007 10:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-106) xsd:attribute ref not
 supported by SchemaBinding
Message-ID: <15518233.1187189101043.JavaMail.jira@cloud.prod.atl2.jboss.com>

xsd:attribute ref not supported by SchemaBinding
------------------------------------------------

                 Key: JBXB-106
                 URL: http://jira.jboss.com/jira/browse/JBXB-106
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions:  JBossXB-2.0.0.CR2
            Reporter: Anil Saldhana
            Priority: Critical


Refer to forum for additional 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 lists.jboss.org  Wed Aug 15 10:53:11 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 10:53:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31992342.1187189591157.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=all ]

Thomas Heute resolved JBPORTAL-1524.
------------------------------------

    Resolution: Won't Fix
      Assignee: Thomas Heute  (was: Julien Viet)

It would break the current themes for people upgrading.

And i don't really see the point, that's internal code. For developers they just have to care about header.jsp and tabs.jsp or replace the PageCustomizerInterceptor

> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 11:10:03 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 11:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3658) Remote classloading
 service - Redesign
In-Reply-To: <2583525.1158255817852.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29697931.1187190603104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3658?page=all ]

Dimitris Andreadis updated JBAS-3658:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
          Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration]  (was: [Compatibility/Configuration, Documentation (Ref Guide, User Guide, etc.)])
         Assignee:     (was: Tom  Elrod)
         Priority: Major  (was: Critical)

Tom's gone.

> 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
>
> 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 lists.jboss.org  Wed Aug 15 11:16:01 2007
From: jira-events at lists.jboss.org (Roman Kalyakin (JIRA))
Date: Wed, 15 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1627) Problem
 destroying service
 portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
In-Reply-To: <12607797.1186753680992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24638282.1187190961517.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1627?page=all ]

Roman Kalyakin updated JBPORTAL-1627:
-------------------------------------

    Attachment: JBPORTAL-1627.patch

A small patch that fixes reloading of portal-basic-samples.

> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> ------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1627
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1627
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: JBPORTAL-1627.patch
>
>
> On AS shutdown:
> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> java.lang.reflect.UndeclaredThrowableException
>         at $Proxy0.destroy(Unknown Source)
>         at org.jboss.system.ServiceController.destroy(ServiceController.java:577)
>         at org.jboss.system.ServiceController.shutdown(ServiceController.java:714)
>         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.server.ServerImpl$ShutdownHook.shutdownServices(ServerImpl.java:1079)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1037)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
> Caused by: javax.management.InstanceNotFoundException: portal:service=ContentRenderer,type=GoogleWidgetPortletInstance is not registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:653)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
>         ... 15 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 lists.jboss.org  Wed Aug 15 11:26:03 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Wed, 15 Aug 2007 11:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-138) error dialogue
 appears on task panel of properties for task node
In-Reply-To: <21642934.1186578244471.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17467375.1187191563994.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-138?page=comments#action_12372306 ] 
            
Ross McDonald commented on GPD-138:
-----------------------------------

Hi,

sorry for the delay.... so I discovered that what makes a difference, at least in reproducing this bug on my system, is you need to select and overwrite the value in the 'name' field on the general panel on the properties dialogue in addition to the steps listed in my original description.  If you do not change the name of the newly added task node, this error does not occurr.

Hope that helps,

cheers

Ross


> error dialogue appears on task panel of properties for task node
> ----------------------------------------------------------------
>
>                 Key: GPD-138
>                 URL: http://jira.jboss.com/jira/browse/GPD-138
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta1
>         Environment: os x macbok pro, eclipse 3.3.0
>            Reporter: Ross McDonald
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: stacktrace.txt
>
>
> Hi,
> when working with the designer in eclipse, if I put a new task node on the screen, immediately enter a value against the name on the 'general' panel under properties, then click on the tasks panel under properties, I get an error dialogue with the following details :
> Reason:
> 0
> 'An error has occurred. See error log for more details.
> 0
> On the other hand, if after entering a name, I click on the description input field, but do not enter anything, then click on the task panel under properties, there is no 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 lists.jboss.org  Wed Aug 15 12:10:10 2007
From: jira-events at lists.jboss.org (Kenny MacLeod (JIRA))
Date: Wed, 15 Aug 2007 12:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1711) HTMLAdaptorServlet
 updateAttributes bug?
Message-ID: <818985.1187194210318.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1711?page=comments#action_12372315 ] 
            
Kenny MacLeod commented on JBAS-1711:
-------------------------------------

18 months since last comment.  Can we add this back on the roadmap, please, it's a trivial fix.

> HTMLAdaptorServlet updateAttributes bug?
> ----------------------------------------
>
>                 Key: JBAS-1711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1711
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1
>            Reporter: SourceForge User
>            Priority: Minor
>
> SourceForge Submitter: raja05 .
> UpdateAttributes method in HtmlAdaptorServlet has a
> section of code something like
>       while( paramNames.hasMoreElements() )
>       {
>          String param = (String) paramNames.nextElement();
>          if( param.equals("name") ||
> param.equals("action") )
>             continue;
>          String value = request.getParameter(param);
>          log.trace("name="+param+", value='"+value+"'");
>          // Ignore null values, these are empty
> write-only fields
>          if( value == null || value.length() == 0 )
>             continue;
>          attributes.put(param, value);
>       }
> The check for value == null || value.length() == 0 is
> kind of wrong for my case. 
> Im trying to use a XMBean that would store the values
> from the JMX-Console to a filestore that i have created
> using Properties.load(not the
> ObjectStreamPersistenceManager but something along the
> line that uses the Property.save to store the data in a
> name=value fashion).
> The problem im getting is that if i want to clear out
> any of the attributes that have been set already, the
> above code comes to the check of value.length() == 0
> and since its blank, just moves to the next request
> param. I would like to remove this check from there so
> that even though i blank out my value, i need that to
> get persisted. 
> Please let me know if you need a detailed explanation
> or if the above is not clear
> I just need the value.length() == 0 check removed but
> not sure if thats going to cause an issue somewhere else.
> Thanks a bunch
> Raja

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 12:10:10 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 12:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-575) Join and state
 transfer violates virtual synchrony
Message-ID: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>

Join and state transfer violates virtual synchrony
--------------------------------------------------

                 Key: JGRP-575
                 URL: http://jira.jboss.com/jira/browse/JGRP-575
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.6


ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 12:20:01 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 15 Aug 2007 12:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1711) HTMLAdaptorServlet
 updateAttributes bug?
Message-ID: <12087897.1187194801299.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1711?page=comments#action_12372319 ] 
            
Dimitris Andreadis commented on JBAS-1711:
------------------------------------------

I think the side effect of what you want, would be to re-set to null all values that are empty, not just the one you alter.

> HTMLAdaptorServlet updateAttributes bug?
> ----------------------------------------
>
>                 Key: JBAS-1711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1711
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1
>            Reporter: SourceForge User
>            Priority: Minor
>
> SourceForge Submitter: raja05 .
> UpdateAttributes method in HtmlAdaptorServlet has a
> section of code something like
>       while( paramNames.hasMoreElements() )
>       {
>          String param = (String) paramNames.nextElement();
>          if( param.equals("name") ||
> param.equals("action") )
>             continue;
>          String value = request.getParameter(param);
>          log.trace("name="+param+", value='"+value+"'");
>          // Ignore null values, these are empty
> write-only fields
>          if( value == null || value.length() == 0 )
>             continue;
>          attributes.put(param, value);
>       }
> The check for value == null || value.length() == 0 is
> kind of wrong for my case. 
> Im trying to use a XMBean that would store the values
> from the JMX-Console to a filestore that i have created
> using Properties.load(not the
> ObjectStreamPersistenceManager but something along the
> line that uses the Property.save to store the data in a
> name=value fashion).
> The problem im getting is that if i want to clear out
> any of the attributes that have been set already, the
> above code comes to the check of value.length() == 0
> and since its blank, just moves to the next request
> param. I would like to remove this check from there so
> that even though i blank out my value, i need that to
> get persisted. 
> Please let me know if you need a detailed explanation
> or if the above is not clear
> I just need the value.length() == 0 check removed but
> not sure if thats going to cause an issue somewhere else.
> Thanks a bunch
> Raja

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:01:01 2007
From: jira-events at lists.jboss.org (Kenny MacLeod (JIRA))
Date: Wed, 15 Aug 2007 13:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1711) HTMLAdaptorServlet
 updateAttributes bug?
Message-ID: <27087083.1187197261200.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1711?page=comments#action_12372324 ] 
            
Kenny MacLeod commented on JBAS-1711:
-------------------------------------

Yeah, OK.  I think should get fixed somehow, though, it can be quiie annoying to not be able to clear the attribute values without having to enter dummy whitespace.

> HTMLAdaptorServlet updateAttributes bug?
> ----------------------------------------
>
>                 Key: JBAS-1711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1711
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1
>            Reporter: SourceForge User
>            Priority: Minor
>
> SourceForge Submitter: raja05 .
> UpdateAttributes method in HtmlAdaptorServlet has a
> section of code something like
>       while( paramNames.hasMoreElements() )
>       {
>          String param = (String) paramNames.nextElement();
>          if( param.equals("name") ||
> param.equals("action") )
>             continue;
>          String value = request.getParameter(param);
>          log.trace("name="+param+", value='"+value+"'");
>          // Ignore null values, these are empty
> write-only fields
>          if( value == null || value.length() == 0 )
>             continue;
>          attributes.put(param, value);
>       }
> The check for value == null || value.length() == 0 is
> kind of wrong for my case. 
> Im trying to use a XMBean that would store the values
> from the JMX-Console to a filestore that i have created
> using Properties.load(not the
> ObjectStreamPersistenceManager but something along the
> line that uses the Property.save to store the data in a
> name=value fashion).
> The problem im getting is that if i want to clear out
> any of the attributes that have been set already, the
> above code comes to the check of value.length() == 0
> and since its blank, just moves to the next request
> param. I would like to remove this check from there so
> that even though i blank out my value, i need that to
> get persisted. 
> Please let me know if you need a detailed explanation
> or if the above is not clear
> I just need the value.length() == 0 check removed but
> not sure if thats going to cause an issue somewhere else.
> Thanks a bunch
> Raja

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:46:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 15 Aug 2007 13:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-792) Provide to the
 client local address of a TCP/IP connection, as seen from the server
Message-ID: <17112881.1187199961180.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide to the client local address of a TCP/IP connection, as seen from the server
-----------------------------------------------------------------------------------

                 Key: JBREM-792
                 URL: http://jira.jboss.com/jira/browse/JBREM-792
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


When org.jboss.remoting.Client.addListener() creates a callback org.jboss.remoting.transport.Connector, by default it calls InetAddress.getLocalHost().getHostAddress() to get a local address for the callback org.jboss.remoting.InvokerLocator.  If the machine happens to have multiple addresses, getLocalHost() might return the wrong one.  A solution, due to Ovidiu Feodorov, is to implement an internal invocation to which the server replies by returning the remote address of the connection over which the invocation was made.

This solution has been implemented for the socket transport (and bisocket, by inheritance) in conjunction with JBREM-781.  It should be implemented for the other transports. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:48:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-575) Join and state
 transfer violates virtual synchrony
In-Reply-To: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7906536.1187200081151.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-575?page=all ]

Vladimir Blagojevic resolved JGRP-575.
--------------------------------------

    Resolution: Done

Change set:
ConcurrentStartupTest.java 1.23
Flush.java 1.63

> Join and state transfer violates virtual synchrony
> --------------------------------------------------
>
>                 Key: JGRP-575
>                 URL: http://jira.jboss.com/jira/browse/JGRP-575
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:50:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-575) Join and state
 transfer violates virtual synchrony
In-Reply-To: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15888546.1187200201159.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-575?page=all ]

Vladimir Blagojevic updated JGRP-575:
-------------------------------------

    Comment: was deleted

> Join and state transfer violates virtual synchrony
> --------------------------------------------------
>
>                 Key: JGRP-575
>                 URL: http://jira.jboss.com/jira/browse/JGRP-575
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:50:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-575) Join and state
 transfer violates virtual synchrony
In-Reply-To: <21755767.1187194210433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21338620.1187200201284.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-575?page=comments#action_12372331 ] 
            
Vladimir Blagojevic commented on JGRP-575:
------------------------------------------

Change set:
ConcurrentStartupTest.java 1.23
FLUSH.java 1.63

> Join and state transfer violates virtual synchrony
> --------------------------------------------------
>
>                 Key: JGRP-575
>                 URL: http://jira.jboss.com/jira/browse/JGRP-575
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> ConcurrentStartupTest was conceived prior to implementation of a solution for JGRP-236. Upon initial integration of code for join and state transfer (JGRP-236), it was discovered that ConcurrentStartupTest was failing. Closer inspection revealed that a joining member, after joining and receiving state, would also receive messages from a previous view thus violating virtual synchrony (that is if FLUSH was present, if it was not we don't care).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 13:55:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-236) Combine join and
	state transfer
Message-ID: <1023668.1187200501995.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-236?page=all ]

Vladimir Blagojevic resolved JGRP-236.
--------------------------------------

    Resolution: Done

Change set:
org/jgroups/protocols/FD_SOCK.java 1.66
org/jgroups/protocols/TUNNEL.java 1.44
org/jgroups/protocols/Discovery.java 1.32
org/jgroups/protocols/LOOPBACK.java 1.25
org/jgroups/protocols/TP.java 1.150
org/jgroups/protocols/pbcast/FLUSH.java 1.62
org/jgroups/protocols/pbcast/ParticipantGmsImpl.java 1.26
org/jgroups/protocols/pbcast/GMS.java 1.110
org/jgroups/protocols/pbcast/STREAMING_STATE_TRANSFER.java 1.49
org/jgroups/protocols/pbcast/ClientGmsImpl.java 1.50
org/jgroups/protocols/pbcast/CoordGmsImpl.java 1.70
org/jgroups/protocols/pbcast/STATE_TRANSFER.java 1.72
org/jgroups/protocols/pbcast/GmsImpl.java 1.24
org/jgroups/stack/ProtocolStack.java 1.50
org/jgroups/stack/StateTransferInfo.java 1.14
org/jgroups/Event.java 1.47
org/jgroups/JChannel.java 1.141
org/jgroups/demos/Draw.java 1.46

> Combine join and state transfer
> -------------------------------
>
>                 Key: JGRP-236
>                 URL: http://jira.jboss.com/jira/browse/JGRP-236
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase.
> The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener.
> - The JOIN_REQ contains the boolean
> - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending
>   the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK),
>   we send it back to the joining member(s), and the RESUME sending 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 lists.jboss.org  Wed Aug 15 13:57:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 15 Aug 2007 13:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-566) Write article about
 FLUSH and Multiplexer
In-Reply-To: <3046420.1185216587208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28664328.1187200621085.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-566?page=all ]

Vladimir Blagojevic resolved JGRP-566.
--------------------------------------

    Resolution: Done

Article written and given to Bob for further processing.

> Write article about FLUSH and Multiplexer
> -----------------------------------------
>
>                 Key: JGRP-566
>                 URL: http://jira.jboss.com/jira/browse/JGRP-566
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> Article should target developers familiar with JGroups looking to exploit new features namely FLUSH and Multiplexer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 14:34:01 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Wed, 15 Aug 2007 14:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1085) Rule fires before
 calling fireAllRules
Message-ID: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule fires before calling fireAllRules
--------------------------------------

                 Key: JBRULES-1085
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Markus Reitz
         Assigned To: Mark Proctor


Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to

  public static void main(String ... args) {
    try {
      DroolsTest test=new DroolsTest(new File(args[0]));
      
      SpecialString first42 =new SpecialString("42");
      SpecialString second42=new SpecialString("42");
      
      System.out.println("Inserting ...");
      
      test.getSession().insert(new SpecialString("World"));
      test.getSession().insert(first42);
      test.getSession().insert(second42);

      System.out.println("Done.");
      
      System.out.println("Firing rules ...");
      
      test.getSession().fireAllRules();
      
      System.out.println("Done.");
    }
    catch (Exception ex) {
      ex.printStackTrace();
    }
  }

and using the rule

  package test

  rule "Strange rule"

    when
      not(exists(x : SpecialString() and
                 forall(y : SpecialString(this!=x)
                            SpecialString(this==y, text=="Universe"))))

    then
      System.out.println("Condition satisfied");
  end

leads to the following output:

  Condition satisfied
  Inserting ...
  Done.
  Firing rules ...
  Condition satisfied
  Done.

The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 

      System.out.println("Condition satisfied");

is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 14:41:01 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 14:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-148) NPE opening GPD
Message-ID: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE opening GPD
---------------

                 Key: GPD-148
                 URL: http://jira.jboss.com/jira/browse/GPD-148
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
            Reporter: Gavin King
         Assigned To: Koen Aers


This is with JBoss Tools beta 3.

ava.lang.NullPointerException
	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
	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:400)
	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)


The jPDL file is from the Seam DVDStore example:

<?xml version="1.0"?>

<process-definition 
	name="OrderManagement"
	xmlns="urn:jbpm.org:jpdl-3.1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
	>

    <start-state name="start">
        <transition to="approval"/>
    </start-state>

    <task-node name="approval" end-tasks="true">
        <task name="approve" description="Review order">
           <assignment pooled-actors="reviewers"/>
        </task>
        <!--
        <task name="approve">
           <assignment actor-id="manager"/>
        </task>
        -->
        <transition name="cancel"  to="cancelled"/>
        <transition name="approve" to="process"/>
        <transition name="reject"  to="cancelled"/>
    </task-node>

    <task-node name="process">
        <task name="ship" description="Ship order">
           <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
        </task>
        <transition name="shipped" to="complete">
            <action expression="#{afterShipping.log}"/>
        </transition>
    </task-node>

    <end-state name="complete"/>
    
    <end-state name="cancelled"/>
    
</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 lists.jboss.org  Wed Aug 15 14:48:01 2007
From: jira-events at lists.jboss.org (Jim Moran (JIRA))
Date: Wed, 15 Aug 2007 14:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4610) <method-attributes>
 configuration
 for MDBs in jboss.xml descriptor is not included in the dtd
Message-ID: <25944699.1187203681163.JavaMail.jira@cloud.prod.atl2.jboss.com>

<method-attributes> configuration for MDBs in jboss.xml descriptor is not included in the dtd
---------------------------------------------------------------------------------------------

                 Key: JBAS-4610
                 URL: http://jira.jboss.com/jira/browse/JBAS-4610
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB2, EJB3
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
            Reporter: Jim Moran
         Assigned To: Scott M Stark
            Priority: Minor


The jboss_4_2.dtd does not allow for <method-attributes> element and sub-elements even though support for this feature has been added in 4.2.0 per JBAS-3321

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 15:07:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 15 Aug 2007 15:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1028) Cleanup
	groupmember startup
In-Reply-To: <20025793.1186597429469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10242990.1187204821290.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1028?page=all ]

Tim Fox closed JBMESSAGING-1028.
--------------------------------

    Resolution: Done

> Cleanup groupmember startup
> ---------------------------
>
>                 Key: JBMESSAGING-1028
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1028
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Cleanup the group member startup so we ensure that view change precedes state arrival precedes messages.
> Add sanity checks to ensure this is the 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 lists.jboss.org  Wed Aug 15 15:17:10 2007
From: jira-events at lists.jboss.org (Anh Vuong (JIRA))
Date: Wed, 15 Aug 2007 15:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1086) InitialFact
 should not be shadowed
Message-ID: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>

InitialFact should not be shadowed
----------------------------------

                 Key: JBRULES-1086
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Anh Vuong
         Assigned To: Mark Proctor


If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:

2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
ialFactImpl
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
        at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
        at java.lang.ClassLoader.loadClass (Unknown Source)
        at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
        at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
        at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
        at org.drools.reteoo.Rete.assertObject(Rete.java:145)
        at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
        at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
        at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
        at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 15:31:01 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 15:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5051279.1187206261784.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372344 ] 
            
Gavin King commented on GPD-148:
--------------------------------

Another problem:


org.dom4j.DocumentException: Error on line 3 of document  : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity.
	at org.dom4j.io.SAXReader.read(SAXReader.java:355)
	at org.dom4j.io.SAXReader.read(SAXReader.java:271)
	at org.jbpm.gd.common.editor.AbstractContentProvider.addNotationInfo(Unknown Source)
	at org.jbpm.gd.common.editor.GraphPage.initInput(Unknown Source)
	at org.jbpm.gd.common.editor.GraphPage.init(Unknown Source)
	at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:186)
	at org.jbpm.gd.common.editor.Editor.addPage(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.initGraphPage(Unknown Source)
	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
	at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:263)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2721)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:138)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:194)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:175)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:268)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:244)
	at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:50)
	at org.eclipse.ui.actions.RetargetAction.run(RetargetAction.java:220)
	at org.eclipse.ui.internal.navigator.CommonNavigatorManager$3.open(CommonNavigatorManager.java:181)
	at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:820)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
	at org.eclipse.core.runtime.Platform.run(Platform.java:857)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:46)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:193)
	at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:818)
	at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1079)
	at org.eclipse.ui.navigator.CommonViewer.handleOpen(CommonViewer.java:353)
	at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1183)
	at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:263)
	at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:257)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:297)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
	at org.eclipse.swt.widgets.Control.sendTrackEvents(Control.java:2734)
	at org.eclipse.swt.widgets.Control.kEventControlTrack(Control.java:1953)
	at org.eclipse.swt.widgets.Widget.controlProc(Widget.java:367)
	at org.eclipse.swt.widgets.Display.controlProc(Display.java:835)
	at org.eclipse.swt.internal.carbon.OS.CallNextEventHandler(Native Method)
	at org.eclipse.swt.widgets.Tree.kEventMouseDown(Tree.java:2363)
	at org.eclipse.swt.widgets.Widget.mouseProc(Widget.java:1262)
	at org.eclipse.swt.widgets.Display.mouseProc(Display.java:2817)
	at org.eclipse.swt.internal.carbon.OS.SendEventToEventTarget(Native Method)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2936)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)

This is with the following pageflow file:

<pageflow-definition	
	xmlns="http://jboss.com/products/seam/pageflow"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation=
	    "http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-2.0.xsd" 
	name="numberGuess">
   
   <start-page name="displayGuess" view-id="/numberGuess.jsp">
      <redirect/>
      <transition name="guess" to="drools"/>
   </start-page>
  
   <decision name="drools">

      <handler class="org.jboss.seam.drools.DroolsDecisionHandler">
         <workingMemoryName>workingMemory</workingMemoryName>
         <assertObjects>
            <element>#{game}</element>
            <element>#{guess}</element>
         </assertObjects>
      </handler>

      <transition to="displayGuess"/>
      <transition name="lose" to="lose"/>
      <transition name="win" to="win"/>
      
   </decision>
   
   <page name="win" view-id="/win.jsp">
   	  <end-conversation />
      <redirect/>
   </page>
   
   <page name="lose" view-id="/lose.jsp">
      <end-conversation />
      <redirect/>
   </page>
   
</pageflow-definition>


> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:33:01 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 15:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32022255.1187206381157.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372345 ] 
            
Gavin King commented on GPD-148:
--------------------------------

Excuse me. The second problem is with the following pageflow:


<pageflow-definition 
	xmlns="http://jboss.com/products/seam/pageflow"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation=
	    "http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-2.0.xsd"
	name="numberGuess">
   
   <start-page name="displayGuess" view-id="/numberGuess.jspx">
      <redirect/>
      <transition name="guess" to="evaluateGuess">
         <action expression="#{numberGuess.guess}"/>
      </transition>
      <transition name="giveup" to="giveup"/>
      <transition name="cheat" to="cheat"/>
   </start-page>
   
   <decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">
      <transition name="true" to="win"/>
      <transition name="false" to="evaluateRemainingGuesses"/>
   </decision>
   
   <decision name="evaluateRemainingGuesses" expression="#{numberGuess.lastGuess}">
      <transition name="true" to="lose"/>
      <transition name="false" to="displayGuess"/>
   </decision>
   
   <page name="giveup" view-id="/giveup.jspx">
      <redirect/>
      <transition name="yes" to="lose"/>
      <transition name="no" to="displayGuess"/>
   </page>
   
   <process-state name="cheat">
      <sub-process name="cheat"/>
      <transition to="displayGuess"/>
   </process-state>

   <page name="win" view-id="/win.jspx">
      <end-conversation/>
      <redirect/>
   </page>
   
   <page name="lose" view-id="/lose.jspx">
      <end-conversation/>
      <redirect/>
   </page>
   
</pageflow-definition>


> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:41:20 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 15:41:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21748512.1187206880875.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372348 ] 
            
Koen Aers commented on GPD-148:
-------------------------------

Gavin, I assume there is also a file with graphical information. Can you specify these as well?

> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:52:18 2007
From: jira-events at lists.jboss.org (Gavin King (JIRA))
Date: Wed, 15 Aug 2007 15:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31997980.1187207538739.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372350 ] 
            
Gavin King commented on GPD-148:
--------------------------------

You mean a .gpd file?

I deleted them, to get a "fresh start".

> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 15:58:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Aug 2007 15:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-148) NPE opening GPD
In-Reply-To: <25732906.1187203261180.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <490833.1187207881286.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-148?page=comments#action_12372352 ] 
            
Koen Aers commented on GPD-148:
-------------------------------

The first problem is probably due to the comment, which is apparently not handled appropriately.
I'll track down the other problem and try to fix both tomorrow.

> NPE opening GPD
> ---------------
>
>                 Key: GPD-148
>                 URL: http://jira.jboss.com/jira/browse/GPD-148
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Gavin King
>         Assigned To: Koen Aers
>
> This is with JBoss Tools beta 3.
> ava.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.TaskNodeDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ProcessDefinitionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.getSemanticElement(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.initSourcePage(Unknown Source)
> 	at org.jbpm.gd.common.editor.Editor.createPages(Unknown Source)
> 	at org.jbpm.gd.jpdl.editor.JpdlEditor.createPages(Unknown Source)
> 	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> 	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> 	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> 	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> 	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299)
> 	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179)
> 	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:400)
> 	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256)
> 	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209)
> 	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:499)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
> 	at org.eclipse.ui.internal.PartStack.add(PartStack.java:485)
> 	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
> 	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217)
> 	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207)
> 	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774)
> 	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673)
> 	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719)
> 	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
> 	at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625)
> 	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572)
> 	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556)
> 	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:340)
> 	at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:328)
> 	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:190)
> 	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519)
> 	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504)
> 	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295)
> 	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> 	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2952)
> 	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
> 	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
> 	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
> 	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
> 	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
> 	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
> 	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
> 	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> 	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> 	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> 	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.equinox.launcher.Main.invokeFramework(Main.java:504)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> The jPDL file is from the Seam DVDStore example:
> <?xml version="1.0"?>
> <process-definition 
> 	name="OrderManagement"
> 	xmlns="urn:jbpm.org:jpdl-3.1"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="urn:jbpm.org:jpdl-3.1 http://jbpm.org/xsd/jpdl-3.1.xsd"
> 	>
>     <start-state name="start">
>         <transition to="approval"/>
>     </start-state>
>     <task-node name="approval" end-tasks="true">
>         <task name="approve" description="Review order">
>            <assignment pooled-actors="reviewers"/>
>         </task>
>         <!--
>         <task name="approve">
>            <assignment actor-id="manager"/>
>         </task>
>         -->
>         <transition name="cancel"  to="cancelled"/>
>         <transition name="approve" to="process"/>
>         <transition name="reject"  to="cancelled"/>
>     </task-node>
>     <task-node name="process">
>         <task name="ship" description="Ship order">
>            <assignment pooled-actors="#{shipperAssignment.pooledActors}"/>
>         </task>
>         <transition name="shipped" to="complete">
>             <action expression="#{afterShipping.log}"/>
>         </transition>
>     </task-node>
>     <end-state name="complete"/>
>     
>     <end-state name="cancelled"/>
>     
> </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 lists.jboss.org  Wed Aug 15 16:25:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Aug 2007 16:25:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
In-Reply-To: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20352839.1187209519569.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4593?page=all ]

Brian Stansberry updated JBAS-4593:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116213

Opened a forum thread with some preliminary diagnostic info.

> Leak in org/jboss/mx/loading/UnifiedClassLoader3
> ------------------------------------------------
>
>                 Key: JBAS-4593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Scott M Stark
>
> [description pasted from support case]
> After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:
> found a path to the target: 26093 (depth: 5)
> 0 0 Heap root
> 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
> 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
> 160611 0 Instance: [Ljava/lang/Object;
> 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
> 217357 0 Instance: Ljavax/management/Notification;
> 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;
> So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.
> Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 16:51:01 2007
From: jira-events at lists.jboss.org (Joe Son (JIRA))
Date: Wed, 15 Aug 2007 16:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1087) Context Assistant
 that shows list of filtered DSL does not work on DRL editor
Message-ID: <8059624.1187211061284.JavaMail.jira@cloud.prod.atl2.jboss.com>

Context Assistant that shows list of filtered DSL does not work on DRL editor
-----------------------------------------------------------------------------

                 Key: JBRULES-1087
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1087
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
         Environment: Windows 2000, Drools 4.0, Eclipse 3.2.2
            Reporter: Joe Son
         Assigned To: Mark Proctor
             Fix For:  4.0.0.GA



DRL FILE:
package rules
 
import com.nationwide.pc.rules.TrexoWrapUC40;
 
expander UC40Dsl.dsl
rule	"Neither Correct Or Complete Audit For High AP"
	salience 1800
	activation-group "UC40"
	when
		UC40 has
		- additional prem >= 25000.0 Or returned premium >= 5000.0
		- task type != "Correct Audit"
		- task type != "Complete Audit Review"
	then
		Set RuleResult "Verify Audit Accuracy"
		Log result "Verify Audit Accuracy"
		Dispatch work item
end

On previous versions, the context assistant show the list of DSL mappings available for me to use.  This one, it doesn't.  When I type - followed by Cntr+Space it sounds a windows error sound.

When I simply type Cntr+Space, it shows list of DRL keywords plust my imported class 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 lists.jboss.org  Wed Aug 15 18:07:01 2007
From: jira-events at lists.jboss.org (Jeff Wang (JIRA))
Date: Wed, 15 Aug 2007 18:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-139) Cannot add tasks to
	the task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5441749.1187215621334.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-139?page=comments#action_12372379 ] 
            
Jeff Wang commented on GPD-139:
-------------------------------

It looks like this is fixed in the 3.1 release candidate.  

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 18:09:01 2007
From: jira-events at lists.jboss.org (Jeff Wang (JIRA))
Date: Wed, 15 Aug 2007 18:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-149) Creating tasks by
 editing XML source will prevent the XML file from being re-opened
Message-ID: <5015540.1187215741100.JavaMail.jira@cloud.prod.atl2.jboss.com>

Creating tasks by editing XML source will prevent the XML file from being re-opened
-----------------------------------------------------------------------------------

                 Key: GPD-149
                 URL: http://jira.jboss.com/jira/browse/GPD-149
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: Eclipse 3.3, Designer 3.1.0 CR
            Reporter: Jeff Wang
         Assigned To: Koen Aers


When you create new tasks by editing the source, it will break the process definition and not allow you to re-open it in Eclipse.

Steps to recreate:

1) Create a new process definition
2) Create a task node using the GUI
3) Switch to the source tab
4) Copy the task xml tag
5) Rename the task name to something unique
6) Close the file
7) Re-open using the JBPM editor



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 18:55:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 18:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1543350.1187218501640.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1614?page=all ]

Thomas Heute resolved JBPORTAL-1614.
------------------------------------

    Resolution: Done

Resolved, thanks for reporting this issue !

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 18:55:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 15 Aug 2007 18:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15702549.1187218502107.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1614?page=all ]

Thomas Heute updated JBPORTAL-1614:
-----------------------------------

    Fix Version/s: 2.8 Final

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 19:19:11 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 15 Aug 2007 19:19:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5543457.1187219951527.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4422?page=comments#action_12372390 ] 
            
Richard Achmatowicz commented on JBAS-4422:
-------------------------------------------

1. Twiddle is a command line tool which allows sending MBeanServer commands to an application server and receiving the results. 
Twiddle has a -s <hostname> option. Using this option tells Twiddle to use that hostname when doing a JNDI lookup to get the MBeanServerConnection proxy it needs to communicate with the MBeanServer. 
Use of the -s option to cause JNDI to do a lookup on the testsuite AS instance node0 was commented out in TwiddleUnitTestCase:

     if (isWindows())
     {
        command.add("cmd");
        command.add("/C");
        command.add("twiddle");
        //command.add("-s");
        //command.add(getServerHost());
        command.addAll(Arrays.asList(args));
     }
     else
     {
        command.add("/bin/sh");
        command.add("-c");
        String twiddleCmd = "./twiddle.sh ";
        //twiddleCmd += "-s ";
        //twiddleCmd += getServerHost();
        twiddleCmd += makeTwiddleArgs(args);
        command.add(twiddleCmd);
     }

Reinstating the -s option fixes the problem with the test case, as the command getServerHost() returns the correct name for the host on which the AS was started (e.g. localhost, or 192.23.1.21), the JNDI lookup succeeds, the MBeanServerConnection proxy is obtained, and the MBeanServerCommand is executed.

I have checked this on Windows.

  


> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Stan Silvert
>            Priority: Trivial
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Wed Aug 15 19:19:11 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 19:19:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4445299.1187219951716.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372391 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

Barry - what do you mean by testing a rule? My take on this is that in different environments you have different rules included/excluded (not just different versions of rules) - my point of confusion is how this can work? How do you isolate testing to just a rule or rules - aren't you testing the system behaviour as a whole? 

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 19:39:01 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 15 Aug 2007 19:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27271866.1187221141086.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4422?page=comments#action_12372396 ] 
            
Richard Achmatowicz commented on JBAS-4422:
-------------------------------------------

2. What is more interesting is explaining why TwiddleUnitTestCase, with the -s still commented out, was passing on RHEL and HPUX, but failing on Windows and Solaris. This was the state of affairs in AS 4.2 RC7. 
In that case, the AS testsuite was started using the parameters:
-u to specify an alternate multicast address (instead of the default 230.0.0.4) 
-node0 to specify the binding to a local IP address (insterad of the default localhost)

The TwiddleUnitTestCase, without the -s option, would in the first instance try to connect to JNDI using localhost:1099. Because no AS was bound to that host/port, the connection would fail. Then, JNDI
autodiscovery would send out a multicast message on 230.0.0.4:1102 to see if any AS instances were listening on that address. Because the testsuite was started with the -u option, the AS instance running as part of the testsuite would be listening for multiucast messages on a multicast address other than 230.0.0.4, but on the same port 1102. On Windows and Solaris, in order for a multicast message to be correctly received, both the address and the port on the message must match the address and the port which the receiver is listening on.
Thus, in the case of Windows (and Solaris), the mulicast messages were not received by the AS instance started by the testsuite, auto-discovery failed, and the TwiddleUnitTestCase could not succeed in obtaining an MBeanServerConnection to any AS instance, and so the test failed.

On the other hand, when the same test was run on RHEL and HPUX, the same sequence of events occurred, up to the point at which autodiscovery was initiated. But due to the "bug" in RHEL and HPUX, for a multicast message to be received by a receiver, only the multicast message port and the multicast receiver port need match, despite any differences in multicast address (contact Brian Stansberry for more details!). The multicast message was thus received, the AS instance offered itself as a JNDI server, the MBeanServerConnection was retrieved by the TwiddleUnitTestCase, and the test passed.

That is my understanding of why the test passed on RHEL and HPUX, but failed on Solaris and Windows.

    

> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Stan Silvert
>            Priority: Trivial
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Wed Aug 15 19:43:01 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 15 Aug 2007 19:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9842559.1187221381261.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4422?page=comments#action_12372400 ] 
            
Richard Achmatowicz commented on JBAS-4422:
-------------------------------------------

In any case, it looks as though the -s option should be reinstated, as this is a test of Twiddle's ability to process MBean operations, and not a test of JNDI auto-discovery in a twiddle context.

I'll make the change and test all platforms tomorrow.


> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Stan Silvert
>            Priority: Trivial
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Wed Aug 15 21:17:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1039) Add Number Guess
 example with Rule Flow
In-Reply-To: <21507599.1185671567073.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12298301.1187227021278.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1039?page=all ]

Mark Proctor closed JBRULES-1039.
---------------------------------

    Resolution: Done

> Add Number Guess example with Rule Flow
> ---------------------------------------
>
>                 Key: JBRULES-1039
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1039
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Create a number guess example, similar to Seams example, but with text input.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:19:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30374718.1187227141167.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1048?page=comments#action_12372420 ] 
            
Mark Proctor commented on JBRULES-1048:
---------------------------------------

completion seems to work now, can we close this off now?

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Wed Aug 15 21:19:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1064) "->" notation for
 predicates missing in documentation
In-Reply-To: <17875154.1186470049576.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28249885.1187227141497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1064?page=all ]

Mark Proctor closed JBRULES-1064.
---------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

> "->" notation for predicates missing in documentation
> -----------------------------------------------------
>
>                 Key: JBRULES-1064
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1064
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Dr. Gernot Starke
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> the notation "->" for adressing complex terms is missing from 4.0.0 documentation.
> It has been "return value operator" in 3.0.6:
> <quoted from 3.0.6>
> Example 3.13. Return Value operator
> Person( girlAge : age, sex = "F" )
> Person( boyAge : age -> ( girlAge.intValue() == boyAge.intValue() + 2 ), sex = 'M' )
> </quoted>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:21:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1081) Repository
 exception occurs duing opening, creation of the rules
In-Reply-To: <6488947.1187050921606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25588337.1187227261334.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1081?page=all ]

Mark Proctor closed JBRULES-1081.
---------------------------------

    Resolution: Rejected

Not a bug

> Repository exception occurs duing opening, creation of the rules
> ----------------------------------------------------------------
>
>                 Key: JBRULES-1081
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1081
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: Standard version of BRMS
>            Reporter: Joe Son
>         Assigned To: Fernando Meyer
>            Priority: Minor
>
> I've downloaded the BRMS standalone and got the Apache server up and running.  I have not changed any default values and left it as is.
> I wanted to get the feel for how the system works first.  However, When I try to create new DRL or open existing example drl, I get the following error:
> javax.jcr.RepositoryException: failed to retrieve item state of item 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent: failed to read property state: 1527c3bc-9bc9-4673-af2c-8c05755d7482/{http://www.jboss.org/drools-repository/1.0}binaryContent
> It seems like the issue stems from Repository but I can't find any other documentation online about these types of issues.
> It created a "Repository" directory under bin as a default.  Did not change any values on repository.xml. 
> Any help would be great. =)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:21:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9150471.1187227261531.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1083?page=all ]

Mark Proctor updated JBRULES-1083:
----------------------------------

    Fix Version/s: 4.0.1

> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:21:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7764042.1187227261935.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1076?page=all ]

Mark Proctor updated JBRULES-1076:
----------------------------------

    Fix Version/s: 4.0.1

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Mark Proctor
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Wed Aug 15 21:23:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1020) BRMS Custom Rule
 Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13253067.1187227393751.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=all ]

Mark Proctor updated JBRULES-1020:
----------------------------------

    Fix Version/s: 4.0.1

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 21:23:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6365424.1187227393908.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1086?page=all ]

Mark Proctor updated JBRULES-1086:
----------------------------------

    Fix Version/s: 4.0.1

> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:23:14 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:23:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1085) Rule fires before
 calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20145772.1187227394090.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1085?page=all ]

Mark Proctor updated JBRULES-1085:
----------------------------------

    Fix Version/s: 4.0.1

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:25:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1079) Problem with "!="
 field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21224299.1187227501299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1079?page=all ]

Mark Proctor updated JBRULES-1079:
----------------------------------

    Fix Version/s: 4.0.1

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Wed Aug 15 21:25:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10019544.1187227501848.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12372422 ] 
            
Mark Proctor commented on JBRULES-1065:
---------------------------------------

I've left this open as Edson thinks he can make it check the field name on the class in this situation.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 15 21:25:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1065) Unable to return
 Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9411161.1187227502012.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=all ]

Mark Proctor updated JBRULES-1065:
----------------------------------

    Fix Version/s: 4.0.1

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 15 21:25:02 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1028) importing .brxml
 into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26155441.1187227502282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=all ]

Mark Proctor updated JBRULES-1028:
----------------------------------

    Fix Version/s: 4.0.1

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Wed Aug 15 21:27:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18939101.1187227621366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1053?page=all ]

Mark Proctor updated JBRULES-1053:
----------------------------------

    Fix Version/s: 4.0.1

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:27:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1023) Typing the
 parameter to be replace by DSL/DRL replacement
In-Reply-To: <30190376.1184942567175.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31590509.1187227621593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1023?page=all ]

Mark Proctor updated JBRULES-1023:
----------------------------------

    Fix Version/s: FUTURE

> Typing the parameter to be replace by DSL/DRL replacement
> ---------------------------------------------------------
>
>                 Key: JBRULES-1023
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1023
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: christian bastin
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>
> We have a very long DSL including more 150 diff?rent lines (wich could be very similar). We have no posibility to be sure of the replacement operarted by the parsing.  We often dicover problem that force us to move the order of the lines in the DSL. This is an simple example of what I think could be improved.
>  
> If you have a DSL
> test {code} is {value}
> this could replace this 2 rules in the DRL
> rule "Rule-1"
> 	when
> 		test 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> rule "Rule-1"
> 	when
> 		test 10 + 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> I would like the ability to type the parameter of my DSL, for example with regular expression.
> test {code|[0-9]+} is {value|[0-9]+}
> so the only rule available for replacement should be the first rule ("Rule-1").  The other rule would not find a replacement and should be implemented in the DSL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Aug 15 21:31:05 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11405800.1187227865904.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1054?page=all ]

Mark Proctor updated JBRULES-1054:
----------------------------------

        Fix Version/s: 4.0.1
    Affects Version/s:  4.0.0.GA
                           (was: 4.0.1)

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Wed Aug 15 21:31:06 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8101889.1187227866525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1055?page=all ]

Mark Proctor updated JBRULES-1055:
----------------------------------

    Fix Version/s: 4.0.1

> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:31:06 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1066)
 org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not
 serializable
In-Reply-To: <23034283.1186562329494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5160081.1187227866684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1066?page=all ]

Mark Proctor updated JBRULES-1066:
----------------------------------

    Fix Version/s: 4.0.1

> org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not serializable
> ---------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1066
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1066
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: seam cvs (2007-08-05), which includes drools 4.0.0.GA, I believe
>            Reporter: Matt Drees
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> I sometimes get a java.io.NotSerializableException: org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction when restarting my seam webapp.  It seems that the problem is simply that WorkingMemoryReteAssertAction doesn't implement Serializable.  This email (http://osdir.com/ml/java.drools.user/2006-12/msg00163.html) seems to indicate that it should, but it apparently hasn't been 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 lists.jboss.org  Wed Aug 15 21:31:07 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:31:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1071)
 BinaryRuleBaseLoader doesn't accept custom ClassLoader
In-Reply-To: <2403729.1186687983991.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30694257.1187227867080.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1071?page=all ]

Mark Proctor updated JBRULES-1071:
----------------------------------

    Fix Version/s: 4.0.1

> BinaryRuleBaseLoader doesn't accept custom ClassLoader
> ------------------------------------------------------
>
>                 Key: JBRULES-1071
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1071
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Vladimir Schafer
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> AddPackage method of class BinaryRuleBaseLoader accepts custom classloader as a parameter, but this isn't propagated to DroolsObjectInputStream in addPackage method call. So custom class loading isn't available when constructing RuleBases from JBRMS packaged files.
> Error is in file org.drools.util.BinaryRuleBaseLoader.java, Core module, line 81. Code ObjectInputStream oin = new DroolsObjectInputStream( in ); should be changed to ObjectInputStream oin = new DroolsObjectInputStream( in, classLoader ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:33:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1087) Context Assistant
 that shows list of filtered DSL does not work on DRL editor
In-Reply-To: <8059624.1187211061284.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6477458.1187227981160.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1087?page=all ]

Mark Proctor closed JBRULES-1087.
---------------------------------

    Fix Version/s: 4.0.1
                       (was:  4.0.0.GA)
       Resolution: Done

This we already discussed this and its because the file is not named .dslr, which I believe you already have working now.

> Context Assistant that shows list of filtered DSL does not work on DRL editor
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1087
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1087
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>         Environment: Windows 2000, Drools 4.0, Eclipse 3.2.2
>            Reporter: Joe Son
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> DRL FILE:
> package rules
>  
> import com.nationwide.pc.rules.TrexoWrapUC40;
>  
> expander UC40Dsl.dsl
> rule	"Neither Correct Or Complete Audit For High AP"
> 	salience 1800
> 	activation-group "UC40"
> 	when
> 		UC40 has
> 		- additional prem >= 25000.0 Or returned premium >= 5000.0
> 		- task type != "Correct Audit"
> 		- task type != "Complete Audit Review"
> 	then
> 		Set RuleResult "Verify Audit Accuracy"
> 		Log result "Verify Audit Accuracy"
> 		Dispatch work item
> end
> On previous versions, the context assistant show the list of DSL mappings available for me to use.  This one, it doesn't.  When I type - followed by Cntr+Space it sounds a windows error sound.
> When I simply type Cntr+Space, it shows list of DRL keywords plust my imported class 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 lists.jboss.org  Wed Aug 15 21:37:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1066)
 org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not
 serializable
In-Reply-To: <23034283.1186562329494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <366238.1187228221179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1066?page=all ]

Mark Proctor closed JBRULES-1066.
---------------------------------

    Resolution: Done

> org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction is not serializable
> ---------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1066
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1066
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: seam cvs (2007-08-05), which includes drools 4.0.0.GA, I believe
>            Reporter: Matt Drees
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> I sometimes get a java.io.NotSerializableException: org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction when restarting my seam webapp.  It seems that the problem is simply that WorkingMemoryReteAssertAction doesn't implement Serializable.  This email (http://osdir.com/ml/java.drools.user/2006-12/msg00163.html) seems to indicate that it should, but it apparently hasn't been 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 lists.jboss.org  Wed Aug 15 21:41:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1071)
 BinaryRuleBaseLoader doesn't accept custom ClassLoader
In-Reply-To: <2403729.1186687983991.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13307364.1187228461124.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1071?page=all ]

Mark Proctor closed JBRULES-1071.
---------------------------------

    Resolution: Done

> BinaryRuleBaseLoader doesn't accept custom ClassLoader
> ------------------------------------------------------
>
>                 Key: JBRULES-1071
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1071
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Vladimir Schafer
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> AddPackage method of class BinaryRuleBaseLoader accepts custom classloader as a parameter, but this isn't propagated to DroolsObjectInputStream in addPackage method call. So custom class loading isn't available when constructing RuleBases from JBRMS packaged files.
> Error is in file org.drools.util.BinaryRuleBaseLoader.java, Core module, line 81. Code ObjectInputStream oin = new DroolsObjectInputStream( in ); should be changed to ObjectInputStream oin = new DroolsObjectInputStream( in, classLoader ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:43:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33500037.1187228581163.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1054?page=all ]

Mark Proctor updated JBRULES-1054:
----------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Wed Aug 15 21:43:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6874359.1187228581362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1055?page=all ]

Mark Proctor updated JBRULES-1055:
----------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:45:24 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20173715.1187228724906.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1086?page=comments#action_12372424 ] 
            
Mark Proctor commented on JBRULES-1086:
---------------------------------------

wierd as Rete node clearly stops InitialFactImpl from being shadowed:
            String pkgName = (pkg != null) ? pkg.getName() : "";
            if ( "org.drools.reteoo".equals( pkgName ) || "org.drools.base".equals( pkgName ) ) {
                // We don't shadow internal classes
                this.shadowEnabled = false;
                this.shadowClass = null;
                this.instantiator = null;
                return;
            }


> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:47:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 21:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1052) When Inserting
 a fact cannot set a String field
In-Reply-To: <1292464.1185911829398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11582327.1187228821419.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1052?page=comments#action_12372425 ] 
            
Mark Proctor commented on JBRULES-1052:
---------------------------------------

I don't think I see this now in the latest trunk, has someone fixed this? Can someone else verify and close this.

> When Inserting a fact cannot set a String field
> -----------------------------------------------
>
>                 Key: JBRULES-1052
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1052
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> A String field only let me put in numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 21:52:01 2007
From: jira-events at lists.jboss.org (Tong Lee (JIRA))
Date: Wed, 15 Aug 2007 21:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11897630.1187229121223.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12372426 ] 
            
Tong Lee commented on JBRULES-1065:
-----------------------------------

Thank you so much Mark!!!

The feature we were looking for is the example below from the blog...
  http://blog.athico.com/2007/05/jboss-rules-expressiveness-goes-to-next.html
  Cheese( newPrice == ( oldPrice * 1.10 ) )

We're going live next month and we would love to use this feature even if we have to use the Milestone Release.  Please update this thread when there is a milestone build for us to try.

Thanks again...


> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 15 22:10:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <732391.1187230201128.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372430 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

How are the rules marked as "tested" and who sets the effective dates for testing? is it manual? 

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:35:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33337627.1187231701113.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372434 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

One idea on how to do this as an advanced feature: 

 have a config file on the classpath that specifies the selectors available. They are a class that implements certain interfaces. Out of the box there are none, but if you add one in, then you can choose it in the GUI when you go to build a package (it will show up a list of them, you pick the appropriate one) - that allows users to define them in any way they see fit. 

This does NOT however address fields that don't currently exist (like tested dates etc).

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:37:19 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:37:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1020) BRMS Custom Rule
 Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7414232.1187231839607.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=all ]

Michael Neale updated JBRULES-1020:
-----------------------------------

    Comment: was deleted

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:37:19 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:37:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25058697.1187231839800.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372435 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

One idea on how to do this as an advanced feature:

 have a config file on the classpath that specifies the selectors available. They are a class that implements certain interfaces. Out of the box there are none, but if you add one in, then you can choose it in the GUI when you go to build a package (it will show up a list of them, you pick the appropriate one) - that allows users to define them in any way they see fit.

This does NOT however address fields that don't currently exist (like tested dates etc).

Optionally, could provide a drop down of status boxes, and perhaps a selector for categories or other attributes to filter purely in the GUI (however that will not automate things, just provide a GUI to choose from).

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Wed Aug 15 22:37:20 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:37:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1036) dialect errors
 if after import declarations
In-Reply-To: <1942890.1185648467658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17298969.1187231840083.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1036?page=all ]

Michael Neale reassigned JBRULES-1036:
--------------------------------------

    Assignee: Michael Neale  (was: Edson Tirelli)

> dialect errors if after import declarations
> -------------------------------------------
>
>                 Key: JBRULES-1036
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1036
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> In the Shopping example if I have the dialect after the imports it 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 lists.jboss.org  Wed Aug 15 22:53:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 15 Aug 2007 22:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1023) Typing the
 parameter to be replace by DSL/DRL replacement
In-Reply-To: <30190376.1184942567175.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20937615.1187232781170.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1023?page=all ]

Michael Neale reassigned JBRULES-1023:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

This is a nice to have, but for 4.2 at the earliest.

> Typing the parameter to be replace by DSL/DRL replacement
> ---------------------------------------------------------
>
>                 Key: JBRULES-1023
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1023
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: christian bastin
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> We have a very long DSL including more 150 diff?rent lines (wich could be very similar). We have no posibility to be sure of the replacement operarted by the parsing.  We often dicover problem that force us to move the order of the lines in the DSL. This is an simple example of what I think could be improved.
>  
> If you have a DSL
> test {code} is {value}
> this could replace this 2 rules in the DRL
> rule "Rule-1"
> 	when
> 		test 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> rule "Rule-1"
> 	when
> 		test 10 + 10 is 10
> 	then 
> >		System.out.println("test 1 OK");
> end
> I would like the ability to type the parameter of my DSL, for example with regular expression.
> test {code|[0-9]+} is {value|[0-9]+}
> so the only rule available for replacement should be the first rule ("Rule-1").  The other rule would not find a replacement and should be implemented in the DSL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Aug 15 23:03:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:03:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1085) Rule fires
 before calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4624951.1187233393609.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1085?page=comments#action_12372437 ] 
            
Mark Proctor commented on JBRULES-1085:
---------------------------------------

With latest trunk code I couldn't replicate this. I have added the test to our generation integration tests and enhanced it. 
See testNestedCorelatedRulesWithForall
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/test/java/org/drools/integrationtests/FirstOrderLogicTest.java
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/test/resources/org/drools/integrationtests/test_NestedCorrelatedRulesWithForall.drl

to verify this yourself please do try the latest snapshot from the URL here:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 23:03:13 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:03:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1085) Rule fires before
 calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13108598.1187233393779.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1085?page=all ]

Mark Proctor closed JBRULES-1085.
---------------------------------

    Resolution: Done

I'll assume this was a bug in 4.0 and is now fixed.

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 15 23:17:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25743368.1187234221286.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1079?page=comments#action_12372439 ] 
            
Mark Proctor commented on JBRULES-1079:
---------------------------------------

You'll get a full cross product. I changed it from two 42 numbers to a 42 and a 42. here is my output, which is correct.
43[org.drools.SpecialString at 111b910]/42[org.drools.SpecialString at e79839]
42[org.drools.SpecialString at e79839]/43[org.drools.SpecialString at 111b910]
World[org.drools.SpecialString at 1d36dfe]/43[org.drools.SpecialString at 111b910]
43[org.drools.SpecialString at 111b910]/World[org.drools.SpecialString at 1d36dfe]
42[org.drools.SpecialString at e79839]/World[org.drools.SpecialString at 1d36dfe]
World[org.drools.SpecialString at 1d36dfe]/42[org.drools.SpecialString at e79839]

Which is what you would expect you have 3 different objects and its going to produce all possible cross procuts, only the this!=x stops it producing a cross product with identity equals objects for x and y.

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Wed Aug 15 23:19:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1079) Problem with "!="
 field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22553527.1187234341125.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1079?page=all ]

Mark Proctor closed JBRULES-1079.
---------------------------------

    Resolution: Rejected

Could not reproduce

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Wed Aug 15 23:52:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 15 Aug 2007 23:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33092166.1187236321269.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1079?page=comments#action_12372441 ] 
            
Mark Proctor commented on JBRULES-1079:
---------------------------------------

I couldn't reproduce this but added this as an itnegration test anyway. see MiscTest.testCrossProductRemovingIdentityEquals()

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Thu Aug 16 00:27:21 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 00:27:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1028) importing .brxml
 into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14474700.1187238441294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=all ]

Michael Neale reassigned JBRULES-1028:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

Fer - we can add some smarts to an existing method (or have a new method) that will take BRXML (ie convert it to DRL and then do it as normal). 

This is for 4.0.1 definately.

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Thu Aug 16 00:29:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 00:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1054) DSL-Editor:
 "Add" button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1845283.1187238541167.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1054?page=all ]

Michael Neale reassigned JBRULES-1054:
--------------------------------------

    Assignee: Fernando Meyer  (was: Michael Neale)

This is a bug in the IDE

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Thu Aug 16 00:31:26 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 00:31:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9751849.1187238686532.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1076?page=all ]

Michael Neale reassigned JBRULES-1076:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 01:56:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 01:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-576) X509Token cannot be
	created
Message-ID: <2173136.1187243761072.JavaMail.jira@cloud.prod.atl2.jboss.com>

X509Token cannot be created
---------------------------

                 Key: JGRP-576
                 URL: http://jira.jboss.com/jira/browse/JGRP-576
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5.1, 2.6


[from Andre Luckow]
I tried to setup a JGroups stack using the AUTH protocol in conjunction
with a X509Token authentication. The protocol stack worked fine before.
After adding the AUTH layer, I received the following error:

2007-08-15 16:40:01,742 ERROR protocols.TCP [Incoming
Thread,AisReplicationGroup,192.168.0.2:8800,run:1445] failed handling
incoming message
java.io.EOFException
        at java.io.DataInputStream.readFully(DataInputStream.java:178)
        at java.io.DataInputStream.readUTF(DataInputStream.java:565)
        at java.io.DataInputStream.readUTF(DataInputStream.java:522)
        at org.jgroups.Message.readFrom(Message.java:737)
        at org.jgroups.protocols.TP.readMessage(TP.java:1214)
        at org.jgroups.protocols.TP.access$700(TP.java:49)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1439)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)

It seems that the getName() method of the X509Token class returns the
wrong classname it should be:

  public String getName() {
        return "org.jgroups.auth.X509Token";
    }

instead of "org.jgroups.auth.X509Token1_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 lists.jboss.org  Thu Aug 16 01:59:17 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 01:59:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-576) X509Token cannot be
	created
In-Reply-To: <2173136.1187243761072.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27336682.1187243957684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-576?page=all ]

Bela Ban resolved JGRP-576.
---------------------------

    Resolution: Done

> X509Token cannot be created
> ---------------------------
>
>                 Key: JGRP-576
>                 URL: http://jira.jboss.com/jira/browse/JGRP-576
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> [from Andre Luckow]
> I tried to setup a JGroups stack using the AUTH protocol in conjunction
> with a X509Token authentication. The protocol stack worked fine before.
> After adding the AUTH layer, I received the following error:
> 2007-08-15 16:40:01,742 ERROR protocols.TCP [Incoming
> Thread,AisReplicationGroup,192.168.0.2:8800,run:1445] failed handling
> incoming message
> java.io.EOFException
>         at java.io.DataInputStream.readFully(DataInputStream.java:178)
>         at java.io.DataInputStream.readUTF(DataInputStream.java:565)
>         at java.io.DataInputStream.readUTF(DataInputStream.java:522)
>         at org.jgroups.Message.readFrom(Message.java:737)
>         at org.jgroups.protocols.TP.readMessage(TP.java:1214)
>         at org.jgroups.protocols.TP.access$700(TP.java:49)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1439)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>         at java.lang.Thread.run(Thread.java:595)
> It seems that the getName() method of the X509Token class returns the
> wrong classname it should be:
>   public String getName() {
>         return "org.jgroups.auth.X509Token";
>     }
> instead of "org.jgroups.auth.X509Token1_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 lists.jboss.org  Thu Aug 16 02:47:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 02:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1088) Spelling check on
	docs
Message-ID: <32085040.1187246821199.JavaMail.jira@cloud.prod.atl2.jboss.com>

Spelling check on docs 
-----------------------

                 Key: JBRULES-1088
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1088
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Fernando Meyer
         Assigned To: Fernando Meyer
             Fix For: 4.0.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 lists.jboss.org  Thu Aug 16 02:55:01 2007
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Thu, 16 Aug 2007 02:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-139) Cannot add tasks to the
	task node
In-Reply-To: <28590515.1186618669480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16123774.1187247301309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-139?page=all ]

Koen Aers closed GPD-139.
-------------------------

    Fix Version/s: jBPM JPDL Designer 3.1.0.GA
       Resolution: Done

OK Thanks, I am closing it

> Cannot add tasks to the task node
> ---------------------------------
>
>                 Key: GPD-139
>                 URL: http://jira.jboss.com/jira/browse/GPD-139
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.beta2
>         Environment: Eclipse 3.3, jdpl 3.2.1, Designer 3.1.0 beta 2, mac book pro, intel core duo, tiger os
>            Reporter: Jeff Wang
>         Assigned To: Koen Aers
>             Fix For: jBPM JPDL Designer 3.1.0.GA
>
>
> I am unable to add new tasks in the task node. When I go to the
> tasks tab in the properties section, the task details panel (containing general, details, assignment, and controller tab) is already showing but there in no task selected. When I try to add a new task, nothing happens. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 02:59:01 2007
From: jira-events at lists.jboss.org (Arsalan Zaidi (JIRA))
Date: Thu, 16 Aug 2007 02:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1089) Getting "could
 not access property ('=')" for a valid rule.
Message-ID: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>

Getting "could not access property ('=')" for a valid rule.
-----------------------------------------------------------

                 Key: JBRULES-1089
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
            Reporter: Arsalan Zaidi
         Assigned To: Mark Proctor


From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
Sent: 13 August 2007 22:16
To: Rules Users List
Subject: Re: [rules-users] could not access property ('=')

Attachments: ATT426765.txt


   This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?

   Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 





when

           $dto : DTO( )

           W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1


then



   Thanks, and hope it helps.

   Edson



2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
  Hi.



  I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.



  I have a rule which looks like this:



  rule "W250.42 Editable"

        when

              DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )

        then

              System.out.println ("0" );

              Action action = createAction("W250.42" , false , true );

              retList.add(action); 

  end 





  both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .



  Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.



  org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47

        at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )

        at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )

        at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )

        at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )

        at org.drools.reteoo.Rete.assertObject(Rete.java:168 )

        at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 

        at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )

        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )

        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )

        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )

        at com.sample.DroolsTest.main( DroolsTest.java:34)

  Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )

        at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )

        at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )

        at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)

        at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 

        at org.mvel.MVEL.executeExpression( MVEL.java:202)

        at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )

        at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )

        ... 10 more

  Caused by: org.mvel.PropertyAccessException: could not access property ('=') 

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )

        at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )

        ... 18 more



  If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.



  I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')



  What seems to be the issue?



  Thanks in advance!



  Regards,



  --Arsalan

        This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 

       

  _______________________________________________
  rules-users mailing list
  rules-users at lists.jboss.org 
  https://lists.jboss.org/mailman/listinfo/rules-users





-- 
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.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 lists.jboss.org  Thu Aug 16 03:01:05 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Thu, 16 Aug 2007 03:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <86500.1187247665943.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372455 ] 
            
Antoine Herzog commented on JBPORTAL-1524:
------------------------------------------

On my opinion : 

"It would break the current themes for people upgrading" : the sooner, the better : later, it will be "to late, there are to many people relying on ...

This code is introducing a "special way of building a region of the page".
It uses a "region", but it is not using a Portlet

very confusing when looking at all this 
not easy to search (grep) thing in the code, with only "dashboard" as key word

"internal code", "developers they just have to care about" :
for out of the box, and for mini customization.

from my experience : for any real portal in prod in a company, the dev + prod people will not just care only about changing a JSP.
They want to see what is going on in this part of the screen, and especially on the login feature.

well, all this is not vital.... it will work out of the box.
My proposal is to help dev people to have :
 - a quicker understanding of how all this work
 - a better way to customize this... as I needed first place 

help customize... help to make portal for prod.



> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 03:06:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 03:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
Message-ID: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>

AUTH: join rejection won't be received because UNICAST drops it
---------------------------------------------------------------

                 Key: JGRP-577
                 URL: http://jira.jboss.com/jira/browse/JGRP-577
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5.1, 2.6


When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Thu Aug 16 03:10:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Aug 2007 03:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11000064.1187248201213.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-577?page=all ]

Bela Ban resolved JGRP-577.
---------------------------

    Resolution: Done

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Thu Aug 16 03:22:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 03:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1036) dialect errors if
 after import declarations
In-Reply-To: <1942890.1185648467658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3783677.1187248921746.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1036?page=all ]

Michael Neale closed JBRULES-1036.
----------------------------------

    Resolution: Done

> dialect errors if after import declarations
> -------------------------------------------
>
>                 Key: JBRULES-1036
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1036
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> In the Shopping example if I have the dialect after the imports it 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 lists.jboss.org  Thu Aug 16 03:38:13 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 03:38:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32241979.1187249893235.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1076?page=comments#action_12372462 ] 
            
Fernando Meyer commented on JBRULES-1076:
-----------------------------------------

I just corrected both maven wrong references as well the operation word. 

about you confusing compiling the source, after download some project from subversion in implicit that you must cding into the downloaded folder, but of course I can explicitly say that; about the 100MB download its the eclipse distro plus some plug ins to build and test the drools eclipse IDE as you can  see the eclipse and documentation optional to build drools from trunk

just type
C:\dev\jbossrules\> mvn clean install





> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 03:40:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 03:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27455656.1187250001237.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1076?page=all ]

Fernando Meyer resolved JBRULES-1076.
-------------------------------------

    Resolution: Done

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 03:42:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 03:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32707335.1187250121128.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372463 ] 
            
Michael Neale commented on JBRULES-1020:
----------------------------------------

OK I think I have a general simple solution:

When building a package, we have a choice to either build the lot, or enter a custom selector criteria (which may be either a SQL style predicate - or an EL expression - haven't decided yet). There can be some buttons to create some sample ones for the common cases. 

however, this does NOT remember any past selectors as entered (only the browser memory will) - but I can't see a way around that unless we create another place to store these "preferences" or selectors for running again at a future time (which seems overkill). 

That or we can allow admins to configure a properties file with a fixed list of selectors to choose from - which option sounds better? 


> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 16 03:52:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 03:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31462516.1187250721536.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372469 ] 
            
Thomas Heute commented on JBPORTAL-1524:
----------------------------------------


"It would break the current themes for people upgrading" : the sooner, the better : later, it will be "to late, there are to many people relying on ...

It's already the case. We cannot break compatibility in 2.6 branch and 2.8 should benefit from a new engine for this.

There are several levels of customization, just modifying the jsps (from my experience it helps a lot of users, but of course not the people who have a visual identity), modifying the layout, and modifying the PageCustomizerInterceptor.

I don't see what the login feature has to do with that, we are talking about "looking pretty"

I will have another look at your code (next time, *please* send a diff, it's easier to look at)  because i really didn't see the benefits specially in terms of customization (except changing the name of those special regions, that appear anywhere else and is documented (i think)). (understanding the code is relative, and doesn't justify a breaking change)


> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 03:58:01 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 16 Aug 2007 03:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4611) HTTP Session Repl
 Cache configured with CacheLoader can cause slow AS shutdowns
Message-ID: <26411619.1187251081159.JavaMail.jira@cloud.prod.atl2.jboss.com>

HTTP Session Repl Cache configured with CacheLoader can cause slow AS shutdowns
-------------------------------------------------------------------------------

                 Key: JBAS-4611
                 URL: http://jira.jboss.com/jira/browse/JBAS-4611
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, JBoss Cache, Web (Tomcat) service
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Galder Zamarreno
         Assigned To: Brian Stansberry
            Priority: Minor


When AS stops, the sessions for that web app are evicted from memory, 
which means removing from the memory locally. We still need the sessions
 in other nodes, for example if we're bringing a node down for maintenance 
in which case, we don't want to remove sessions of the cluster completely. 
We want users to failover to another node and continue as normal.

The code handling this evictions first removes any data in these sessions and
 then tries to check whether this HTTP session has any children nodes in the
 cache so that it can do a complete clearout of the subtree:

JBossCacheWrapper:

   void evictSubtree(Fqn fqn)
   {

      Exception ex = null;
      for (int i = 0; i < RETRY; i++)
      {
         try
         {
            // Evict the node itself first, since if it stores a Pojo
            // that will do everything
            proxy_.evict(fqn);

            // next do a depth first removal; this ensure all nodes
            // are removed, not just their data map
            Set children = proxy_.getChildrenNames(fqn);
...

If no cache loaders were used, this would be fine, it wouldn't find any 
children in memory and would return quickly. A true local call. 
However, for a customer who's using a ClusteredCacheLoader to get around 
some state transfer issues, when AS discovers that this session does 
not contain any children nodes, it goes remote to find them because 
it didn't find them locally (won't find them remotely either):

CacheLoaderInterceptor:

   private boolean mustLoad(DataNode n, Object key)
   {
      return n == null ||
              (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key)));
   }

As the node has been emptied, CLI (CacheLoaderInterceptor) thinks it 
needs to go remote. Same thing would happen with Pojo too (as the 
entire node is emptied). This is an unnecessary trip which is delaying 
the local eviction of sessions.

This would happen regardless of the CacheLoader used.

Two possible solutions come to my mind:
- easy one: call getChildrenNames() before evict and cache in a local variable the 
children Set. getChildrenNames() would land locally cos the fqn exists yet.
- complex one: do a getChildrenNames(Option) passing an option indicating that 
if the lookup fails locally, don't bother going remote.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 04:58:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 16 Aug 2007 04:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-200) Make sure the
 batch and sh files work
Message-ID: <29893530.1187254681124.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-200?page=comments#action_12372474 ] 
            
Stale Pedersen commented on JBAOP-200:
--------------------------------------

changed the classpath import so it would include all jars.
the .sh files where tested against the 2.0.0alpha5 release. need to verify that the .bat files also works before i can close this...

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:12:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1035) Potential
	security issue
In-Reply-To: <6455963.1186598569318.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21845519.1187255521044.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1035?page=all ]

Tim Fox closed JBMESSAGING-1035.
--------------------------------

    Resolution: Rejected

AFAICT there is nothing to fix here

> Potential security issue
> ------------------------
>
>                 Key: JBMESSAGING-1035
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1035
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Need to investigate whether there is an issue here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:20:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2232310.1187256001071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1026?page=all ]

Tim Fox updated JBMESSAGING-1026:
---------------------------------

        Summary: Ensure successfull test run against all supported databases  (was: Ensure successfull test run against all supported databases, also DB2)
    Description: Postgresql, MySQL, Sybase, Oracle, MSSQL

> Ensure successfull test run against all supported databases
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> Postgresql, MySQL, Sybase, Oracle, MSSQL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1090) Simple data field
 enums in BRMS
Message-ID: <21981533.1187257381183.JavaMail.jira@cloud.prod.atl2.jboss.com>

Simple data field enums in BRMS
-------------------------------

                 Key: JBRULES-1090
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1090
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Michael Neale
             Fix For: 4.0.1


Can use MVEL (or something) to store (as a discrete asset) a mapping of fact/fields to value lists. Then these value lists can be used in the Guided editor. 

eg:

Person.age : [1, 2, 3, 4, 5, 6, 7]
Person.sex: [M, F]
Person.classification: [ HIGH, LOW]

these are then used to drive drop downs. 

For extra bonus points, provide a means to display a different value to what is rendered. 
This can then be loaded as a separate map into SCE and loaded up to the client for display as 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 lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1049) Exceptions in
 logs after clustering test run
Message-ID: <28422090.1187257381307.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exceptions in logs after clustering test run
--------------------------------------------

                 Key: JBMESSAGING-1049
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1049
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.GA


After running clustering tests, several exceptions are found in the logs.

These seem innocuous since the test suite passes but we should investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1028) importing
 .brxml into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31463136.1187257381601.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=comments#action_12372479 ] 
            
Michael Neale commented on JBRULES-1028:
----------------------------------------

Fer - perhaps a better way is to update the drools-ant project to be able to deal with all the asset types (basically do what the BRMS ContentPackageAssembler does - but with files) - this would be FAR SUPERIOUR and we can integrate it with the IDE later as well.

ping me with any Q's.

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Thu Aug 16 05:43:01 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 16 Aug 2007 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1632) Impossible to
 deactivate registration in WSRP producer configuration.
Message-ID: <1352609.1187257381672.JavaMail.jira@cloud.prod.atl2.jboss.com>

Impossible to deactivate registration in WSRP producer configuration.
---------------------------------------------------------------------

                 Key: JBPORTAL-1632
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1632
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.2 Final, 2.8 Final


Empty producer-configuration is not authorized in the DTD, in particular.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 05:47:01 2007
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 16 Aug 2007 05:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-184) Parsing more
	than one file
In-Reply-To: <18498056.1183400157724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22375172.1187257621340.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-184?page=all ]

Ales Justin reassigned JBMICROCONT-184:
---------------------------------------

    Assignee: Ales Justin

> Parsing more than one file
> --------------------------
>
>                 Key: JBMICROCONT-184
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-184
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>             Fix For: JBossMC-2.0.0.CR1
>
>
> The AbstractVFSParser has the following limitiation:
>    @Override
>    protected T parse(DeploymentUnit unit, String name, String suffix, T root) throws Exception
>    {
>       // Should we include the deployment
>       // The infrastructure will only check leafs anyway so no need to check here
>       if (name == null && isIncludeDeploymentFile())
>          name = unit.getName();
>       
>       // Try to find the metadata
>       VFSDeploymentUnit vfsDeploymentUnit = (VFSDeploymentUnit) unit;
>       List<VirtualFile> files = vfsDeploymentUnit.getMetaDataFiles(name, suffix);
>       if (files.size() == 0)
>          return null;
>       
>       // TODO remove this limitation
>       if (files.size() > 1)
>          throw new DeploymentException("Only one file is allowed, found=" + files);
>       VirtualFile file = files.get(0);
> This is really also related to the "reparse" that is done for ejb-jar.xml/jboss.xml and [jboss-]web.xml
> There should be parsing deployers that know how to parse multiple files into one object 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 lists.jboss.org  Thu Aug 16 05:52:01 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 16 Aug 2007 05:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1050) Replace usage
 of oswego concurrent with java.util.concurrent
Message-ID: <28748024.1187257921046.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace usage of oswego concurrent with java.util.concurrent
------------------------------------------------------------

                 Key: JBMESSAGING-1050
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1050
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 2.0.0 Beta 1


Now we are Java 5 or later only, we should get rid of all oswego concurrent usage and use java.util.concurrent 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 lists.jboss.org  Thu Aug 16 06:00:01 2007
From: jira-events at lists.jboss.org (Barry Knapp (JIRA))
Date: Thu, 16 Aug 2007 06:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14626304.1187258401345.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372483 ] 
            
Barry Knapp commented on JBRULES-1020:
--------------------------------------


My Definition of Rule Testing:   Testing new rule with existing rules that will be in production with the new rule, in a systems integrated environment.

Here is an example, I have a production server with 100 rules and a rule #1 that says if Driver Age < 21 then set Fact Risky Driver

Due to some change in company policy, I need to replace this rule #1  with 2 new rules.

Rule #2 : if Driver Age < 21 and Driver has no accidents then set Fact Young Driver
Rule #3 : if Driver Age < 21 and Driver has >0 accidents then set Fact Risky Driver


I would need an Integration test environment to test Rule #2 and Rule #3 with all the other 99 production rules, but Rule #1 should not be included in the test environment, since my intention is for Rules #2 and #3 to replace Rule #1.

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 16 06:09:01 2007
From: jira-events at lists.jboss.org (Barry Knapp (JIRA))
Date: Thu, 16 Aug 2007 06:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1020) BRMS Custom
 Rule Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16015263.1187258941125.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=comments#action_12372484 ] 
            
Barry Knapp commented on JBRULES-1020:
--------------------------------------

> How are the rules marked as "tested" and who sets the effective dates for testing? is it manual?

The rules will be manually updated with "Tested", Effective Date, Expiration Date, Test Effective Date and Test Expiration Date by the business user.  In the long run I would like to automate the tested flag to true when the snapshot containing that rule is deployed to the test environment, but no time for that right now.  :-)
[ Show ? ]
Michael Neale [15/Aug/07 10:09 PM] How are the rules marked as "tested" and who sets the effective dates for testing? is it manual?

> have a config file on the classpath that specifies the selectors available. They are a class that implements certain interfaces. Out of the box there
> are none, but if you add one in, then you can choose it in the GUI when you go to build a package (it will show up a list of them, you pick the
> appropriate one) - that allows users to define them in any way they see fit.
> This does NOT however address fields that don't currently exist (like tested dates etc).

This would probably work well for me, since the application will give my class control where I can look up in a custom database table or repository extension for my custom rule properties and values.


> That or we can allow admins to configure a properties file with a fixed list of selectors to choose from - which option sounds better?

The admin configuration of the properties file would be perfect.  The selective deployment script are tightly tied to the rule management process and rule life cycle.  These will be defined one time by IT and probably see little change after that.


> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 16 06:49:01 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 16 Aug 2007 06:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4606) Hypersonic server
 mode TCP socket problem
In-Reply-To: <5093937.1187090041430.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26132182.1187261341501.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4606?page=all ]

Adrian Brock closed JBAS-4606.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Dimitris Andreadis)

This is NOT a JBoss bug.

The underlying cause is a hypersonic error message, raise the issue on that project.

Caused by: java.sql.SQLException: socket creation error
        at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
        at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
        at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
        at org.hsqldb.jdbcDriver.connect(Unknown Source) 

Configuration of thirdparty software within JBoss should be raised in the forums
as help requests NOT as bug reports.

> Hypersonic server mode TCP socket problem
> -----------------------------------------
>
>                 Key: JBAS-4606
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4606
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: Sun JVM, x86_64&i686, RHEL5, JBossAS conf. "default", running as service jbossas.
>            Reporter: Martin Vecera
>
> I wanted to deploy Duke's bank J2EE example. This requires HSQLDB in server mode. The server/deploy/hsqldb-ds.xml is well prepared for switching HSQLDB to server mode, so I did it. This XML file uses ${jboss.bind.address} property to determine HSQLDB binding address.
> I was running JBossAS with 'service jbossas start'. In /etc/sysconfig/jbossas I had JBOSS_IP=127.0.0.1.
> I got the following error:
> 2007-08-14 13:27:30,715 WARN  [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
> org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: socket creation error)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:179)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
>         at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
>         at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:500)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
>         at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
>         at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
>         at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1017)
>         at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.createTableIfNotExists(GeneralPurposeDatabasePersistencePlugin.java:142)
>         at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:104)
>         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 org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         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 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 $Proxy42.start(Unknown Source)
>         at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
>         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 sun.reflect.GeneratedMethodAccessor18.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 $Proxy9.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.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.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:508)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.sql.SQLException: socket creation error
>         at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
>         at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
>         at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
>         at org.hsqldb.jdbcDriver.connect(Unknown Source)
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:171)
>         ... 122 more
> When I replaced the {$jboss.bind.address} (both occurences in hsqldb-ds.xml) with 'localhost' everything was OK.
> So I tried to replace it with 127.0.0.1 and got the same error.
> Then I tried to put the ${jboss.bind.address} property back and changed JBOSS_IP in /etc/sysconfig/jbossas to 'localhost'.
> Well, everything was working then.
> So I returned JBOSS_IP=127.0.0.1 back and voila - everything is OK!!!
> I tried it twice on two different machines. Once I used JBOSS_IP=localhost I was able to use any of the previously mentioned configuration and it was working. VERY STRANGE! After each change I restarted JBossAS completely.
> I tried nslookup at the beginning to see if it is bound corectly:
> [root at xen61 deploy]# nslookup 127.0.0.1
> Server:         10.34.32.125
> Address:        10.34.32.125#53
> 1.0.0.127.in-addr.arpa  name = localhost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 06:52:13 2007
From: jira-events at lists.jboss.org (Antoine Herzog (JIRA))
Date: Thu, 16 Aug 2007 06:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3002189.1187261533098.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372489 ] 
            
Antoine Herzog commented on JBPORTAL-1524:
------------------------------------------

ok
what do you call "send a diff"
what tool ?

> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 07:17:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 07:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1524)
 PageCustomizerInterceptor :
 regionName may be set in service descriptor.
In-Reply-To: <14974441.1183507671432.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14616408.1187263021590.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1524?page=comments#action_12372494 ] 
            
Thomas Heute commented on JBPORTAL-1524:
----------------------------------------

SVN does it if you got the source from SVN

"svn diff"

or simply the "diff" command line on linux (or Cygwin) 

"diff -rub theUntouchedDirectory myDirectory"

r for recusrive
u for unified
b to ignore the changes in number of spaces

or other tools available of Windows (i don't know them but i found the diff tool here: http://gnuwin32.sourceforge.net/packages/diffutils.htm)



> PageCustomizerInterceptor : regionName may be set in service descriptor.
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1524
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1524
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 CR3, 2.6 Final
>         Environment: JBP 2.6 CR3
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: PageCustomizerInterceptor - Patch.zip
>
>
> About the PageCustomizerInterceptor : the 2 regionName may be set in service descriptor.
> It is more customizable, when building/adapting a layout.
> But the best of this is to understand better that this service is providing the content for the two regions in the layout.
> When looking at the layout, you can see the regionName='dashboardnav' defined for the header... 
> But no region of this name in default-object.xml or pages descriptors !
> After some file search, I found this label (dashboardnav) in the PageCustomizerInterceptor.
> It is not easy to understand what's going on in this service...
> As this jsp injection is not very usual, it would be much more easy to understand what's hapening if the region name would be customizable in the service descriptor.
> It also allow to change the names in the layout jsp file : navigation is a word that is in many place in the portal code and descriptor... not easy to follow the track of where are things about these tabs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 07:30:14 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 07:30:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1540) Add description
 column to portlet lists
In-Reply-To: <12933516.1183739992920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15118662.1187263814057.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1540?page=all ]

Thomas Heute resolved JBPORTAL-1540.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

> Add description column to portlet lists
> ---------------------------------------
>
>                 Key: JBPORTAL-1540
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1540
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final, 2.6 Final
>            Reporter: Chris Laprun
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: Picture 3.png
>
>
> With WSRP, Portlets don't always have a useful name, resulting in less than useful portlet lists... See attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 07:54:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 07:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1608) CMS content
 type always display with no decoration
In-Reply-To: <3650382.1185258947112.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15212464.1187265241050.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1608?page=all ]

Thomas Heute resolved JBPORTAL-1608.
------------------------------------

    Fix Version/s: 2.8 Final
       Resolution: Done

> CMS content type always display with no decoration
> --------------------------------------------------
>
>                 Key: JBPORTAL-1608
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1608
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Changing window properties has no 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 lists.jboss.org  Thu Aug 16 08:14:17 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Thu, 16 Aug 2007 08:14:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
Message-ID: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException when the 'result' block of an 'accumulate' function returns null
-------------------------------------------------------------------------------------

                 Key: JBRULES-1091
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Alexandre Gattiker
         Assigned To: Mark Proctor


java.lang.NullPointerException
	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
	at com.sample.DroolsTest.main(DroolsTest.java:28)


Example rule:
rule "Example"
	no-loop true
	when
		$d:		Double()
		from accumulate ( m : Message( $value: status ),
                              init( double total = 0; ),
                              action( System.out.println($value); ),
                              result( null )
                         )
	then
		System.out.println( "xx"); 
		
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 lists.jboss.org  Thu Aug 16 08:18:01 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Thu, 16 Aug 2007 08:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1092) Invalid Java code
 generated from 'accumulate' function with nested classes
Message-ID: <22762348.1187266681169.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invalid Java code generated from 'accumulate' function with nested classes
--------------------------------------------------------------------------

                 Key: JBRULES-1092
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1092
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Alexandre Gattiker
         Assigned To: Mark Proctor


Steps to reproduce:
- Create a sample new project with the Eclipse plugin
- Add following rule to the .drl file
- Execute DroolsTest

rule "AccumulateTest"
	no-loop true
	when
		$d: Double()
		from accumulate ( m : Message( $value: status ),
                              init( double total = 0; ),
                              action( total += $status ),
                              result( total )
                         )
	then
		System.out.println( "ok" ); 
		
end

Exception is:
org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=AccumulateTest, agendaGroup=MAIN, salience=0, no-loop=true]
	com/sample/Rule_AccumulateTest_0.java (27:834) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
	com/sample/Rule_AccumulateTest_0.java (27:869) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
	com/sample/Rule_AccumulateTest_0.java (29:1027) : Syntax error, insert ";" to complete Statement
	com/sample/Rule_AccumulateTest_0.java (29:1027) : $status cannot be resolved
	com/sample/Rule_AccumulateTest_0.java (39:1483) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
	com/sample/Rule_AccumulateTest_0.java (39:1518) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name

	at org.drools.rule.Package.checkValidity(Package.java:408)
	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
	at com.sample.DroolsTest.readRule(DroolsTest.java:64)
	at com.sample.DroolsTest.main(DroolsTest.java:21)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 09:45:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 16 Aug 2007 09:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-103) JBossXB ignores
 non-ignorable white space
In-Reply-To: <20632248.1181214195060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5420982.1187271901533.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-103?page=all ]

Alexey Loubyansky updated JBXB-103:
-----------------------------------

    Affects Version/s:  JBossXB-2.0.0.CR2
                       JBossXB-1.0.0.CR10

> JBossXB ignores non-ignorable white space
> -----------------------------------------
>
>                 Key: JBXB-103
>                 URL: http://jira.jboss.com/jira/browse/JBXB-103
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR10,  JBossXB-2.0.0.CR2
>            Reporter: Carlo de Wolf
>         Assigned To: Alexey Loubyansky
>         Attachments: unit-test.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 lists.jboss.org  Thu Aug 16 09:49:01 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 16 Aug 2007 09:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-103) JBossXB ignores
 non-ignorable white space
In-Reply-To: <20632248.1181214195060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15930909.1187272141769.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-103?page=all ]

Alexey Loubyansky closed JBXB-103.
----------------------------------

    Fix Version/s: JBossXB-2.0.0.CR4
                   JBossXB-1.0.0.CR11
       Resolution: Done

Fixed.

> JBossXB ignores non-ignorable white space
> -----------------------------------------
>
>                 Key: JBXB-103
>                 URL: http://jira.jboss.com/jira/browse/JBXB-103
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR10,  JBossXB-2.0.0.CR2
>            Reporter: Carlo de Wolf
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-2.0.0.CR4, JBossXB-1.0.0.CR11
>
>         Attachments: unit-test.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 lists.jboss.org  Thu Aug 16 10:41:02 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 10:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-567) Add one shot state
 transfer for multiple substates
In-Reply-To: <15276236.1185217071282.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3596151.1187275262467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-567?page=all ]

Vladimir Blagojevic updated JGRP-567:
-------------------------------------

    Comment: was deleted

> Add one shot state transfer for multiple substates
> --------------------------------------------------
>
>                 Key: JGRP-567
>                 URL: http://jira.jboss.com/jira/browse/JGRP-567
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.x
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> Currently (<= 2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is:
> public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 10:41:02 2007
From: jira-events at lists.jboss.org (Satya Satyamoorthy (JIRA))
Date: Thu, 16 Aug 2007 10:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1041) jBPM documentation
 changes to include Deployment and Debug steps.
Message-ID: <21593965.1187275262652.JavaMail.jira@cloud.prod.atl2.jboss.com>

jBPM documentation changes to include Deployment and Debug steps.
-----------------------------------------------------------------

                 Key: JBPM-1041
                 URL: http://jira.jboss.com/jira/browse/JBPM-1041
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Documentation
    Affects Versions: jBPM GPD 3.0.7
         Environment: All
            Reporter: Satya Satyamoorthy
         Assigned To: Tom Baeyens
             Fix For: jBPM GPD 3.0.7


Please add adequate documentation listing the steps to 
1. Deploy the processes to different environments - such as test, user acceptance, production etc. from the RHDS.
2. Set breakpoints and Trace and 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 lists.jboss.org  Thu Aug 16 11:41:01 2007
From: jira-events at lists.jboss.org (Andy Pemberton (JIRA))
Date: Thu, 16 Aug 2007 11:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25811573.1187278861382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372553 ] 
            
Andy Pemberton commented on JBPORTAL-1631:
------------------------------------------

Thomas:

First, I want to mention that I really enjoy JBoss Portal and appreciate all the hard work by you and your team. My company is actively and successfully using JBoss Portal on several client projects. Because I enjoy the product, I have a vested interest in its success in the market.

So - back to the discussion at hand: while I do see some value in targeting CSS to specific user-agents, I also see problems with this approach. 

(a) Typically, this approach relies on the user-agent string from a HTTP header. The problem with this approach is that the user-agent string can be changed and is done so quite frequently. In short, the user-agent string is not a reliable indicator of the client's browser (see: https://addons.mozilla.org/en-US/firefox/addon/59).

(b) A bigger problem, however, is that targeting CSS to particular user agents creates maintainability problems. 
	Example: If I target CSS to FireFox 2 now, the release of FireFox 3 may require that I change/redeploy my code? 
	Example: If I target CSS to IE as a whole (not to a specific version) because of a particular defect in IE7, what happens if this defect gets resolved with IE8? (This was all too often the case with IE6 and IE7).
	Example: Managing separate style sheets for each browser requiring support is a worst case scenario, but *quite* a head-ache

Instead, CSS should be written according to the W3 CSS specifications; either user agents will support a given CSS feature (selector, pseudo-class, etc.) or not.
	-Targeting CSS to particular browsers is counter-productive given the goal of standards-compliant CSS and HTML. 
	-So rather than targeting CSS to a specific web browser, the CSS should be implicitly targeted based on support for a given CSS feature.

Having said that, you might wonder - isn't IE's conditional comment system an example of targeting CSS to a specific user agent?

Well, yes and no. 

Yes - conditional comments *do* target CSS specifically to (or from) IE. So, this is a maintainability problem as noted in point B above. However, because of the specific CSS defects caused by IE's lack of support for W3 standards (see: http://www.positioniseverything.net/, http://www.satzansatz.de/cssd/onhavinglayout.html), targeting CSS to this browser is acceptable and IMHO necessary. Most of the other widely used, modern browsers/rendering engines (Gecko, WebCore, Presto) support the CSS specs to a degree that in almost all cases, targeting specific style sheets to these browsers is not necessary. 

No - Conditional comments are not like traditional CSS user agent targeting, however, because they do not rely on the user-agent HTTP header. Typically, conditional comments are used to send additional CSS rules to IE to override rules set for all other browsers. Basically, it's kind of like punishing IE for not supporting the CSS standards. This means that we *don't* have to manage separate style sheets for all browsers/versions - just for this versions of IE requiring fixes. 

So, Conditional Comments do not have problem A and problem B is an acceptable consequence of the *need* to target CSS to IE. 

For these reasons I think that a module in JBoss Portal that targets CSS to user agents is actually (a) over-architecting the solution and (b) leading away from the standards-compliant nature that JBoss Portal should push for. I think supporting conditional comments alone is the right approach for JBoss Portal.

-----

BTW: I'm not a Microsoft/IE basher. IE7 greatly enhanced its standards support for CSS and HTML. The fact is that a lot of folks still use IE6, which has limited support for CSS/HTML standards.


> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 11:41:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1153) Introduce a
 concept of structural nodes
In-Reply-To: <6252571.1185539387065.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29342151.1187278861503.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1153?page=comments#action_12372554 ] 
            
Manik Surtani commented on JBCACHE-1153:
----------------------------------------

Identified by a boolean flag on the node?

> Introduce a concept of structural nodes
> ---------------------------------------
>
>                 Key: JBCACHE-1153
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1153
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Structural nodes should not be taken into consideration when processing regions for eviction.
> Typically are nodes that do not contain data (and are not intended to contain data), but are used to build 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 lists.jboss.org  Thu Aug 16 11:43:21 2007
From: jira-events at lists.jboss.org (Dave Dibble (JIRA))
Date: Thu, 16 Aug 2007 11:43:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1076) Typos,
 Build Instruction
 problems in Ref Manual, revision 14125 in Section 3.4
In-Reply-To: <2220614.1186942981262.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8427313.1187279001846.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1076?page=all ]

Dave Dibble closed JBRULES-1076.
--------------------------------


Fernando,

Appreciate your patience and help. Maven, subversion, and ant are all new to me, so am learning what is assumed in their use while Jboss Rules is my primary interest. In following along in the manual, the subversion download did show the current directory, but the 'mvn' command in 3.4.1 did not, so I don't feel like a complete dork for not realizing it.  Again, thanks. (Am back on my way.)

> Typos, Build Instruction problems in Ref Manual, revision 14125 in Section 3.4
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-1076
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1076
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.MR3
>         Environment: WinXP
>            Reporter: Dave Dibble
>         Assigned To: Fernando Meyer
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> Section 3.2 - "MAVEN_HOME=D:\java\maven2.0.7" should be "MAVEN_HOME=D:\java\maven-2.0.7"  (missing hyphen)
> Section 3.4.1 - "uses to build" should be "uses Maven to build" (or even, 'has used'). Also "operation system" could be "operating system"
> Section 3.4.1 is a bit confusing in the following way: It starts with where we are - in possession of the source and ready to build - which we *are* by following the prior instructions.  Next it talks about two 'profiles' to 'enable' some modules. Not sure where the profiles are and what 'enabling' does.  However it talks about a 100MB download; since we already have the source downloaded from the Subversion repository, what else are we downloading? Regardless, on running the suggested command  (where Subversion jbossrules is locally at C:\dev\jbossrules) one gets an error:
> C:\dev>mvn -Declipse -Ddocumentation clean install -DlocalEclipseDrop=/dev/jbossrules/local-eclipse-drop-mirror
> [INFO] Scanning for projects...
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Building Maven Default Project
> [INFO]    task-segment: [clean, install]
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for update
> s from central
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin
> s/3/maven-plugins-3.pom
> 6K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven
> -parent-4.pom
> 9K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom
> 3K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-
> plugin/2.1.1/maven-clean-plugin-2.1.1.jar
> 6K downloaded
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xm
> l, but the build is not using one.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Sun Aug 12 11:00:02 MST 2007
> [INFO] Final Memory: 1M/4M
> [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 lists.jboss.org  Thu Aug 16 11:46:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-971) Eviction policy
 based on adaptive replacement
In-Reply-To: <27209315.1171014930036.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31055605.1187279161201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-971?page=all ]

Manik Surtani updated JBCACHE-971:
----------------------------------

    Fix Version/s: 3.0.0
                       (was: 2.1.0.GA)

> Eviction policy based on adaptive replacement
> ---------------------------------------------
>
>                 Key: JBCACHE-971
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-971
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 3.0.0
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Quote from Mircea Markus:
> There is an eviction policy algorithm more efficient than LRU (which I found quite popular) - Adaptive Replacement Policy. The basic idea is to not rely only on the time of last access to the node, but also on the number of time(frequency) a given node was accessed. Here it is a nice description of how it works: http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 11:46:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-1154) Introduce
 ability to mark
 nodes as immortal - i.e., they never get considered for eviction
In-Reply-To: <19979184.1185539627066.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8638178.1187279161340.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1154?page=all ]

Manik Surtani reassigned JBCACHE-1154:
--------------------------------------

    Assignee: Mircea Markus  (was: Manik Surtani)

> Introduce ability to mark nodes as immortal - i.e., they never get considered for eviction
> ------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 11:48:01 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Thu, 16 Aug 2007 11:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-1153) Introduce a
 concept of structural nodes
In-Reply-To: <6252571.1185539387065.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12149677.1187279281063.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1153?page=all ]

Manik Surtani reassigned JBCACHE-1153:
--------------------------------------

    Assignee: Mircea Markus  (was: Manik Surtani)

> Introduce a concept of structural nodes
> ---------------------------------------
>
>                 Key: JBCACHE-1153
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1153
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>
> Structural nodes should not be taken into consideration when processing regions for eviction.
> Typically are nodes that do not contain data (and are not intended to contain data), but are used to build 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 lists.jboss.org  Thu Aug 16 12:15:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Aug 2007 12:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-395) Add support for
 overriding getResources method in java.lang.ClassLoader
Message-ID: <17729683.1187280901159.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for overriding getResources method in java.lang.ClassLoader
-----------------------------------------------------------------------

                 Key: JBBUILD-395
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-395
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


The jboss-test project has a class called
org.jboss.test.classloader.FilteringClassLoader

This class overrides the method getResources(String) in java.lang.Classloader.  This is fine for jdk1.5, but this method is declared final in jdk1.4.  There should be a way to retro translate this to maintain this behaviour in jdk1.4.  Maybe the overriding method should just be removed when the retro translation takes place.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 12:19:01 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Aug 2007 12:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-396) Add support for
 Thread.UncaughtExceptionHandler
Message-ID: <21567461.1187281141341.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for Thread.UncaughtExceptionHandler
-----------------------------------------------

                 Key: JBBUILD-396
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-396
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


The jboss-test project uses the jdk1.5 class Thread.UncaughtExceptionHandler.
Retro should translate this class to something compatible with jdk14

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 12:39:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Aug 2007 12:39:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <16904980.1187282359967.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic reopened JBAS-2299:
-----------------------------------

             

> 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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Thu Aug 16 12:39:20 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Aug 2007 12:39:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <17051241.1187282360647.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.2.2.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.2.2.GA
>
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Thu Aug 16 12:41:01 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Aug 2007 12:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2299) OutOfMemory error when
 repetatively deploying and undeploying with 10 minute interval
Message-ID: <30234851.1187282461795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic closed JBAS-2299.
---------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
       Resolution: Rejected

> 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
>         Attachments: Data.txt, SampleApp.ear, Sampleapp.zip
>
>          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 lists.jboss.org  Thu Aug 16 13:38:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 13:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
Message-ID: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
-----------------------------------------------------------------------------------------------------

                 Key: JBPM-1042
                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: jBPM 3.2.1
Java 1.6 update 2
Windows XP
Run as a standalone Java application. No app server.
Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
            Reporter: Jeff Johnson
         Assigned To: Tom Baeyens


org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".

My ActionHandler.execute() method: 
    public void execute(ExecutionContext executionContext) throws Exception
    {
      // Normally would do stuff here
      // Leave via the default transition
      // When this test case was written, this method would throw when 
      // it tried to enter Node2 because it would try to lock the token but 
      // it is already locked.
      executionContext.leaveNode();
    }
  }

Section 9.5 of the user guide states: "Note the difference
between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.

The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.

// From org.jbpm.graph.def.Node.execute()
public void execute(ExecutionContext executionContext) {
    // if there is a custom action associated with this node
    if (action!=null) {
      try {
        // execute the action
        executeAction(action, executionContext);

      } catch (Exception exception) {
        // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
        // search for an exception handler or throw to the client
        raiseException(exception, executionContext);
      }

    } else {
      // let this node handle the token
      // the default behaviour is to leave the node over the default transition.
      leave(executionContext);
    }
  }

However this appears to conflict with the comments for Token.lock()
 /**
   * locks a process instance for further execution.  A locked token 
   * cannot continue execution.  This is a non-persistent
   * operation.  This is used to prevent tokens being propagated during 
   * the execution of actions.
   * @see #unlock(String) 
   */
  public void lock(String lockOwnerId) {


Originally this test case failed in jBPM 3.2.1 with the following exception
 * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
  at org.jbpm.graph.exe.Token.lock(Token.java:646)
  at org.jbpm.graph.def.Node.enter(Node.java:316)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
  at org.jbpm.graph.def.Transition.take(Transition.java:151)
  at org.jbpm.graph.def.Node.leave(Node.java:393)
  at org.jbpm.graph.def.Node.leave(Node.java:357)
  at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
  at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
  at org.jbpm.graph.def.Action.execute(Action.java:122)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
  at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
  at org.jbpm.graph.def.Node.execute(Node.java:338)
  at org.jbpm.graph.def.Node.enter(Node.java:318)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
  at org.jbpm.graph.def.Transition.take(Transition.java:151)
  at org.jbpm.graph.def.Node.leave(Node.java:393)
  at org.jbpm.graph.node.StartState.leave(StartState.java:70)
  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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
  at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
  at org.jbpm.graph.exe.Token.signal(Token.java:194)
  at org.jbpm.graph.exe.Token.signal(Token.java:139)
  at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
  at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
  at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
  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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
  at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 13:40:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 13:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <102211.1187286001108.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Jeff Johnson updated JBPM-1042:
-------------------------------

    Attachment: SimpleAsyncProcessTest.java

Test case this produces describe exception. Initially written to work with jBPM 3.2.1 code base.

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 13:42:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 13:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8518082.1187286121305.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Jeff Johnson updated JBPM-1042:
-------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4074927#4074927

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 14:13:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 14:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14567134.1187287981266.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1079?page=all ]

Edson Tirelli reopened JBRULES-1079:
------------------------------------

             
Reproduced the problem.

> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Thu Aug 16 14:21:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 14:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1079) Problem with
 "!=" field constraint
In-Reply-To: <24578048.1187029981616.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21449979.1187288461387.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1079?page=all ]

Edson Tirelli resolved JBRULES-1079.
------------------------------------

    Resolution: Done

I was able to reproduce the problem. It was a problem related to the shadow fact generated equals() method. The method was being generated like this:

   public boolean equals( Object object ) {
       if ( this == object || 
            this.delegate == object || 
            this.delegate.equals( object ) ) {
 
            return true;
       }
 
       if (( object == null ) || ( ! ( object instanceof <class> ) ) ) 
            return false;
 
       if( object instanceof ShadowProxy && 
          ( this.delegate == ((ShadowProxy)object).delegate ||
            this.delegate.equals( ((ShadowProxy)object).delegate ) ) ) {
 
            return true;
 
       }
 
       <class> other = (<class>) object;
 
       // for each field:
 
           if ( ! _fieldIsSet ) {
               __field = this.delegate.method();
                __fieldIsSet = true;
           }
 
           // for primitive types
           if ( this.field != other.field ) 
                return false;
 
           // for non primitive types
           if( ( ( this.field == null ) && ( other.field != null ) ) ||
               ( ( this.field != null ) && ( ! this.field.equals( other.field ) ) ) )
                return false;
 
       // if all fields were ok
       return true;
       // or if no fields exists
       return false;
    }

I.e, after failing on previous checks, the shadow fact tried to compare the value for each field, and in case they were all equal, it returned true, causing the unexpected behavior when fields were set to the "42" value in your test.

I removed that part from the equals() method generation and now it is like this:

   public boolean equals( Object object ) {
       if ( this == object || 
            this.delegate == object || 
            this.delegate.equals( object ) ) {
 
            return true;
       }
 
       if (( object == null ) || ( ! ( object instanceof <class> ) ) ) 
            return false;
 
       if( object instanceof ShadowProxy && 
          ( this.delegate == ((ShadowProxy)object).delegate ||
            this.delegate.equals( ((ShadowProxy)object).delegate ) ) ) {
 
            return true;
 
       }
      return false;
  }

As all tests are green, I'm giving it a go and committing.
Please let us know if it fixes your problems.

Thanks for reporting and providing test case.


> Problem with "!=" field constraint
> ----------------------------------
>
>                 Key: JBRULES-1079
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1079
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> The following code illustrates the problem.
> import org.drools.*;
> import org.drools.compiler.*;
> import org.drools.rule.Package;
> import java.io.*;
> public class DroolsTest {
>   private RuleBase        rules;
>   private StatefulSession memory;
>   public DroolsTest(File file) throws Exception {
>     rules =RuleBaseFactory.newRuleBase();
>     memory=rules.newStatefulSession();
>     
>     rules.addPackage(loadPackage(file));
>   }
>   protected Package loadPackage(File file) throws IOException {
>     FileInputStream stream=null;
>     
>     try {
>       stream=new FileInputStream(file);
>     
>       return(loadPackage(stream));
>     }
>     finally {
>       if (stream!=null)
>         stream.close();
>     }
>   }
>   protected Package loadPackage(InputStream stream) throws IOException {
>     try {
>       PackageBuilder builder=new PackageBuilder();
>       builder.addPackageFromDrl(new InputStreamReader(stream));
>       return(builder.getPackage());
>     }
>     catch(Exception ex) {
>       throw new IOException();
>     }
>   }
>   
>   public StatefulSession getSession() {
>     return(memory);
>   }
>   
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(first42));
>       System.out.println("Fact handle: "+test.getSession().getFactHandle(second42));
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> }
> In the above example, three different objects are created and inserted into the working memory of the Drools Engine. Two of the three objects have the same text - "42".
> The class SpecialString uses the standard equals(...) and hashCode(...) implementation:
> public class SpecialString {
>   private String text;
>   
>   public SpecialString(String text) {
>     this.text=text;
>   }
>   
>   public String getText() {
>     return(text);
>   }
>   
>   @Override public String toString() {
>     return(getText()+"["+super.toString()+"]");
>   }
> }
> For the rule
>   package test
>   rule "A test"
>     when
>       x : SpecialString()
>       y : SpecialString(this!=x)
>     then
>       System.out.println(x+"/"+y);
>   end
> The output is 
>   Fact handle: [fid:2:2:42[SpecialString at fde8da]]
>   Fact handle: [fid:3:3:42[SpecialString at e4d6ef]]
>   Firing rules ...
>   42[SpecialString at e4d6ef]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at e4d6ef]
>   42[SpecialString at fde8da]/World[SpecialString at faa824]
>   World[SpecialString at faa824]/42[SpecialString at fde8da]
> I would expect that
>   42[SpecialString at e4d6ef]/42[SpecialString at fde8da]
>   42[SpecialString at fde8da]/42[SpecialString at e4d6ef]
> is also contained in the output, but this is not the 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 lists.jboss.org  Thu Aug 16 14:30:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 14:30:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1085) Rule fires
 before calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23219688.1187289019938.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1085?page=comments#action_12372597 ] 
            
Edson Tirelli commented on JBRULES-1085:
----------------------------------------

I tried this with 4.0GA and was not able to reproduce it either.

If it is still a problem for you, can you please attach a self contained test in a zip file to this ticket? 


> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 14:59:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 14:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17234766.1187290741320.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372601 ] 
            
Thomas Heute commented on JBPORTAL-1631:
----------------------------------------

a) anything in the header can be false, but what the point ? This is not a security issue. You can also lie to the IE conditional comments.

b) no, i am not necessarly talking about a simple mapping, but regular expressions, and default to some stylesheet anyway.
"CSS should be written according to the W3 CSS specifications;" it reminds me an idea of julien to write this standard CSS and create a compiler for different browser but that's a big project as a whole :) (any contributor interested ?)

"isn't IE's conditional comment system an example of targeting CSS to a specific user agent? "

You read in my mind :)

>From my experience i agree that other browser support the standards in a better way but still, you have different behavior even on the same version of FF on Windows or Linux (try the dashboard DnD to have that confirmation). Also you may want a stylesheet for Opera on a computer and Opera on a Nintendo Wii.


Again, the idea is to allow rules like:

If (user-agent is IE <5.5) use CSS a
If (user-agent is IE = 6) use CSS b
If (user-agent is another version of IE) use CSS c
If (user-agent is opera on a wii) use CSS d
otherwise use CSS e

That said, this is not done, but really i think it's the cleaner way. Who knows what Microsoft will decide for IE8 maybe they will stop supporting conditional comments.

I also hate IE ;)



> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:07:10 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 15:07:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1094)
 PackageBuilderConfiguration.setDialectConfiguration() method is not
 correctly setting dialect configurations
Message-ID: <21869476.1187291230433.JavaMail.jira@cloud.prod.atl2.jboss.com>

PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect configurations
------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1094
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1094
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect 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 lists.jboss.org  Thu Aug 16 15:15:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 15:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-491) Multiplexer should
 execute getState for all registered MuxChannel under one FLUSH phase
In-Reply-To: <13148506.1177600470196.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8948693.1187291701605.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-491?page=all ]

Vladimir Blagojevic resolved JGRP-491.
--------------------------------------

    Resolution: Done

Change set:
JChannel.java 1.143
Multiplexer.java 1.64
FLUSH.java 1.64
STATE_TRANSFER.java 1.73
STREAMING_STATE_TRANSFER.java 1.50
StateTransferInfo.java 1.15



> Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-491
>                 URL: http://jira.jboss.com/jira/browse/JGRP-491
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5, 2.4.1
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.6
>
>
> The idea behind MuxChannel state transfer listeners is to trigger all state transfers together and have all or none result for all registered MuxChannels. As currently implemented underlying plumbing with will trigger each transfer under *separate* FLUSH. In order to have it done under one flush we have to do manual flushing in Multiplexer (startFlush/stopFlush) for these transfers T and we should retrofit FLUSH protocol *not to* trigger flushing for each GET_STATE from T. We have two options:
> a) add requireFlush field in StateTransferInfo - that is then passed down with GET_STATE
> - this requires changing signature of JChannel.getState
> b) retrofit FLUSH to detect special handling of GET_STATE
> - at state requester A we record that we requested GET_STATE and if another GET_STATE arrives from A while channel is already flushed do not trigger another 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 lists.jboss.org  Thu Aug 16 15:21:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 15:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-567) Add one shot state
 transfer for multiple substates
In-Reply-To: <15276236.1185217071282.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27683608.1187292061342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-567?page=all ]

Vladimir Blagojevic updated JGRP-567:
-------------------------------------

    Fix Version/s: 3.0
                       (was: 2.6)

We will do this one together with [JGRP-536]

> Add one shot state transfer for multiple substates
> --------------------------------------------------
>
>                 Key: JGRP-567
>                 URL: http://jira.jboss.com/jira/browse/JGRP-567
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.x
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 3.0
>
>
> Currently (<= 2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is:
> public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:21:01 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 16 Aug 2007 15:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-567) Add one shot state
 transfer for multiple substates
In-Reply-To: <15276236.1185217071282.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24163984.1187292061483.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-567?page=all ]

Vladimir Blagojevic updated JGRP-567:
-------------------------------------

    Comment: was deleted

> Add one shot state transfer for multiple substates
> --------------------------------------------------
>
>                 Key: JGRP-567
>                 URL: http://jira.jboss.com/jira/browse/JGRP-567
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.x
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 3.0
>
>
> Currently (<= 2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is:
> public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:23:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 15:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1094)
 PackageBuilderConfiguration.setDialectConfiguration() method is not
 correctly setting dialect configurations
In-Reply-To: <21869476.1187291230433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26855056.1187292181319.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1094?page=all ]

Edson Tirelli closed JBRULES-1094.
----------------------------------

    Resolution: Done

Fixed.

> PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect configurations
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1094
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1094
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> PackageBuilderConfiguration.setDialectConfiguration() method is not correctly setting dialect 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 lists.jboss.org  Thu Aug 16 15:25:17 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 16 Aug 2007 15:25:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32582608.1187292317801.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372610 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

I'm inclined to close this issue since it is a symptom of the other issues. Does not add anything new to what is already known. Comments?

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:38:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 16 Aug 2007 15:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1088) Spelling check
	on docs
In-Reply-To: <32085040.1187246821199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9947909.1187293081101.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1088?page=all ]

Fernando Meyer resolved JBRULES-1088.
-------------------------------------

    Resolution: Done

> Spelling check on docs 
> -----------------------
>
>                 Key: JBRULES-1088
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1088
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Fernando Meyer
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 16 15:44:05 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 16 Aug 2007 15:44:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1095) Deserializing
 Package Objects Consumes Large Amount of Memory
Message-ID: <17599698.1187293445172.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deserializing Package Objects Consumes Large Amount of Memory
-------------------------------------------------------------

                 Key: JBRULES-1095
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1095
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: Windows
            Reporter: Ming Jin
         Assigned To: Mark Proctor


Deserializing the Package objects from storage to memory consumes large amount of memory.  My tests showed that for a serialized size of 1MB, 18MB of memory would be consumed during deserialization, mostly from the method org.drools.rule.Package.readExternal.  A test program with resulting profile data would be uploaded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:46:01 2007
From: jira-events at lists.jboss.org (Ming Jin (JIRA))
Date: Thu, 16 Aug 2007 15:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1095) Deserializing
 Package Objects Consumes Large Amount of Memory
In-Reply-To: <17599698.1187293445172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28208799.1187293561298.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1095?page=all ]

Ming Jin updated JBRULES-1095:
------------------------------

    Attachment: testdrools.zip

> Deserializing Package Objects Consumes Large Amount of Memory
> -------------------------------------------------------------
>
>                 Key: JBRULES-1095
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1095
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>         Attachments: testdrools.zip
>
>
> Deserializing the Package objects from storage to memory consumes large amount of memory.  My tests showed that for a serialized size of 1MB, 18MB of memory would be consumed during deserialization, mostly from the method org.drools.rule.Package.readExternal.  A test program with resulting profile data would be uploaded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:46:01 2007
From: jira-events at lists.jboss.org (Markus Reitz (JIRA))
Date: Thu, 16 Aug 2007 15:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1085) Rule fires
 before calling fireAllRules
In-Reply-To: <7625323.1187202841150.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1850288.1187293561529.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1085?page=comments#action_12372620 ] 
            
Markus Reitz commented on JBRULES-1085:
---------------------------------------

I have a self-contained test which demonstrates the problem in 4.0GA. Do I have to reopen the issue to be able to attach the file?

> Rule fires before calling fireAllRules
> --------------------------------------
>
>                 Key: JBRULES-1085
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1085
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Modifying the main method of the program fragment used in ( http://jira.jboss.com/jira/browse/JBRULES-1079 ) to
>   public static void main(String ... args) {
>     try {
>       DroolsTest test=new DroolsTest(new File(args[0]));
>       
>       SpecialString first42 =new SpecialString("42");
>       SpecialString second42=new SpecialString("42");
>       
>       System.out.println("Inserting ...");
>       
>       test.getSession().insert(new SpecialString("World"));
>       test.getSession().insert(first42);
>       test.getSession().insert(second42);
>       System.out.println("Done.");
>       
>       System.out.println("Firing rules ...");
>       
>       test.getSession().fireAllRules();
>       
>       System.out.println("Done.");
>     }
>     catch (Exception ex) {
>       ex.printStackTrace();
>     }
>   }
> and using the rule
>   package test
>   rule "Strange rule"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> leads to the following output:
>   Condition satisfied
>   Inserting ...
>   Done.
>   Firing rules ...
>   Condition satisfied
>   Done.
> The Drools Engine fires the rule before the method fireAllRules() is called in the main method. As a result, 
>       System.out.println("Condition satisfied");
> is executed twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:52:01 2007
From: jira-events at lists.jboss.org (Andy Pemberton (JIRA))
Date: Thu, 16 Aug 2007 15:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24812147.1187293921685.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372628 ] 
            
Andy Pemberton commented on JBPORTAL-1631:
------------------------------------------

Well, I still feel that this solution is over-architecting the problem but it will certainly solve the business need. I still hold that implementing this feature as you've described it into JBoss Portal will detract from its standards compliance. 

a) Agreed - this is not a security issue but does point out that using the user-agent string to target CSS may not be effective. Conditional comments do not rely on this HTTP header, so it would be harder to "lie" to them.

Anyway, it will be important to ensure that the solution will allow for feeding multiple style sheets to the various user agents. In other words, providing only one if/otherwise set would be a problem. Whereas, multiple if/otherwise blocks would allow a developer to feed a stylesheet  to all browsers, and then a 'corrective' style sheet to versions of IE.

Ah, by the way - that's a cool feature of conditional comments. If IE8 decided to stop supporting them, they would just appear as regular HTML comments. Whereas your solution will require additional processing for EVERY user agent that hits the portal site, conditional comments only make extra work occur for the bad-boy-browser - all other browsers see a comment. 

... and, no takers here on implementing the cross-platform CSS compiler. = ] 

> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:54:03 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 15:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1096) NPE when using
 "exists" with "from"
Message-ID: <994629.1187294043149.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE when using "exists" with "from"
-----------------------------------

                 Key: JBRULES-1096
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1096
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder, Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


NPE when adding a package with the following rule to a rulebase:

package org.drools;

global java.util.List results;

rule "exists with from"
	when
		Cheesery( $cheeses : cheeses ) 
		exists( Cheese( type == "stilton" ) from $cheeses )
	then
		results.add( "true" );
end


java.lang.NullPointerException
	at org.drools.reteoo.builder.BuildUtils.createBetaNodeConstraint(BuildUtils.java:168)
	at org.drools.reteoo.builder.GroupElementBuilder$ExistsBuilder.build(GroupElementBuilder.java:306)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:136)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:109)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:262)
	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:337)
	at org.drools.integrationtests.FirstOrderLogicTest.testExistsWithFrom(FirstOrderLogicTest.java:717)
	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 junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 15:56:01 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Thu, 16 Aug 2007 15:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21242988.1187294161166.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372629 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

A clean unit test that just shows ONE of the problems seems useful.  
I think it's going to be really hard to come up with fixes that work in all contexts, so the more to check against, the better chance the fix will "stick".
So I definitely wouldn't close it, especially after Jeff Johnson found it reproducible.

This appears to be fallout from the recursive execution model, which I've whined about at some length already on the forum as an accident waiting to happen.  I've done some work to unwind the recursion, but don't have time to do full regression-testing.  Here's the essence of it.  I'm sure I've made some naive assumptions, and changes between 3.2 and 3.2.1 may require some adjustments. 

In Node.java, the execute method looks like this (based on 3.2 GA).  Note comments in caps.

=======

  public void execute(ExecutionContext executionContext) {
    // if there is a custom action associated with this node
    if (action!=null) {
      executionContext.setExecutingNode(true);    // RAISE FLAG IN CONTEXT TO SAY WE"RE IN ACTIONHANDLER
      try {
        // execute the action
        action.execute(executionContext);
        executionContext.setExecutingNode(false);  // LOWER FLAG IN CONTEXT

        // CHECK FOR POSTPONED TRANSACTION AND EXECUTE IT NOW
        Transition pendingTransition = executionContext.getPendingTransition();
        if ( pendingTransition != null )
        {
            executionContext.setPendingTransition(null);
            leave(executionContext, pendingTransition);
        }

      } catch (Exception exception) {
        executionContext.setExecutingNode(false);
        executionContext.setPendingTransition(null);
        // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
        // search for an exception handler or throw to the client
        raiseException(exception, executionContext);
      }

    } else {
      // let this node handle the token
      // the default behaviour is to leave the node over the default transition.
      leave(executionContext);
    }
  }

======
The ExecutionContext fields 
  protected Transition pendingTransition = null;
  protected boolean executingNode = false;
have straightforward accessors.  

=========
Node.leave() now starts out:

  public void leave(ExecutionContext executionContext, Transition transition) {

    if (transition==null) throw new JbpmException("can't leave node '"+this+"' without leaving transition");

    // IF WE ARE IN THE MIDDLE OF AN ACTIONHANDLER, WAIT TILL WE'VE FINISHED.
    if ( executionContext.isExecutingNode() )
    {
      assert(executionContext.getPendingTransition() == null);
      executionContext.setPendingTransition(transition);
      return;
    }
 

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:10:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 16 Aug 2007 16:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30346174.1187295001322.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372632 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

I agree it is a nice and a well written unit test (nice change from comments by some others ;-) ) and a analysis (nice addition by you btw) but isn't this test identical to what is in the jobExecutorDbTest? Or do I mis something?



> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:26:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 16 Aug 2007 16:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1096) NPE when using
 "exists" with "from"
In-Reply-To: <994629.1187294043149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22319853.1187295961241.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1096?page=all ]

Edson Tirelli closed JBRULES-1096.
----------------------------------

    Resolution: Done

Fixed and added integration tests. This is a regression introduced when we refactored patterns to have a source field.

> NPE when using "exists" with "from"
> -----------------------------------
>
>                 Key: JBRULES-1096
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1096
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> NPE when adding a package with the following rule to a rulebase:
> package org.drools;
> global java.util.List results;
> rule "exists with from"
> 	when
> 		Cheesery( $cheeses : cheeses ) 
> 		exists( Cheese( type == "stilton" ) from $cheeses )
> 	then
> 		results.add( "true" );
> end
> java.lang.NullPointerException
> 	at org.drools.reteoo.builder.BuildUtils.createBetaNodeConstraint(BuildUtils.java:168)
> 	at org.drools.reteoo.builder.GroupElementBuilder$ExistsBuilder.build(GroupElementBuilder.java:306)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:136)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:109)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:262)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:337)
> 	at org.drools.integrationtests.FirstOrderLogicTest.testExistsWithFrom(FirstOrderLogicTest.java:717)
> 	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 junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:30:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 16 Aug 2007 16:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1056) Performance of
 RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase
 with large number of packages.
In-Reply-To: <2724825.1186088939724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31172573.1187296201338.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1056?page=all ]

Mark Proctor closed JBRULES-1056.
---------------------------------

    Resolution: Done

fixed :)

> Performance of RuleBase().addPackage(.) goes down on sub sequent instances of RuleBase with large number of packages.
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1056
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1056
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: TestDrools.java, testdrools.zip, TestObject.java
>
>
> I encountered a strange behavior when trying to test the performance of rule registration, meaning to add Package's to a new instance of RuleBase.  I ran the same test 5 times in a sequence, and the RuleBase instance was discarded right away.  The test ran with different different number of packages, 20, 50, 100, and 200.  The results are as the followings:
>  
> Added 20 packages to rulebase in 0:00:0.15
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.21
> Added 20 packages to rulebase in 0:00:0.301
> Added 20 packages to rulebase in 0:00:0.18
> Added 20 packages to rulebase 5 times in 0:00:1.051
>  
> Added 50 packages to rulebase in 0:00:0.17
> Added 50 packages to rulebase in 0:00:1.422
> Added 50 packages to rulebase in 0:00:1.252
> Added 50 packages to rulebase in 0:00:1.322
> Added 50 packages to rulebase in 0:00:1.331
> Added 50 packages to rulebase 5 times in 0:00:5.497
>  
> Added 100 packages to rulebase in 0:00:0.19
> Added 100 packages to rulebase in 0:00:5.278
> Added 100 packages to rulebase in 0:00:5.297
> Added 100 packages to rulebase in 0:00:5.228
> Added 100 packages to rulebase in 0:00:5.327
> Added 100 packages to rulebase 5 times in 0:00:21.32
>  
> Added 200 packages to rulebase in 0:00:0.22
> Added 200 packages to rulebase in 0:00:21.691
> Added 200 packages to rulebase in 0:00:21.481
> Added 200 packages to rulebase in 0:00:21.642
> Added 200 packages to rulebase in 0:00:21.341
> Added 200 packages to rulebase 5 times in 0:01:26.385
>  
> As you can see, the timing of creating first RuleBase instance is always good, while the subsequent one's were very bad.  Is there an attribute I could adjust in configuration to improve the performance for this scenario?  Please advise if there is other alternatives.  I would be glad to provide details if needed.
> The following test program would demonstrate the problem:
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Random;
> import java.io.StringReader;
> import java.io.IOException;
> import org.drools.rule.Package;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.DroolsParserException;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 2:53:50 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestDrools {
>   private static final String ALPHABET= "abcdefghijklmnopqrstuvwxyz";
>   private static final String DRL_TEMPLATE  =
>           "package testpackage\n" +
>           "import test.TestObject\n"+
>           "rule \"testrule_$1\"\n" +
>           "  when\n" +
>           "    h:TestObject(value1==\"$2\", value2 in (\"$3\"))\n" +
>           "  then\n" +
>           "    h.setResult(\"$4\");\n" +
>           "end";
>   private int count;
>   public TestDrools(int count) {
>     this.count  = count;
>   }
>   public void run() throws Exception {
>     List<String>  drls  = generateDrls();
>     List<Package> pkgs  = generatePackages(drls);
>     for (int i = 0; i < 3; i++) {
>       addPackages(pkgs, i+1);
>     }
>   }
>   private static RuleBase addPackages(List<Package> pkgs, int id) throws Exception {
>     long     time  = System.currentTimeMillis();
>     RuleBase rb  = RuleBaseFactory.newRuleBase();
>     for (Package pkg : pkgs)
>       rb.addPackage(pkg);
>     System.out.println("Added "+pkgs.size()+" packages to rulebase"+id+" in "+
>                        (System.currentTimeMillis()-time)/1000.0+" seconds");
>     return rb;
>   }
>   private List<String> generateDrls() {
>     List<String>  list  = new ArrayList<String>(count);
>     for (int i = 0; i < count; i++) {
>       list.add(getDrl(i));
>     }
>     return list;
>   }
>   private static List<Package> generatePackages(List<String> drls) throws DroolsParserException, IOException {
>     List<Package> list  = new ArrayList<Package>(drls.size());
>     for (String drl : drls) {
>       PackageBuilder  builder = new PackageBuilder();
>       builder.addPackageFromDrl(new StringReader(drl));
>       list.add(builder.getPackage());
>     }
>     return list;
>   }
>   private String getDrl(int seed) {
>     String  drl = DRL_TEMPLATE.replace("$1", Integer.toString(seed));
>     drl = drl.replace("$2", getRandomString());
>     drl = drl.replace("$3", getRandomString());
>     return drl.replace("$4", getRandomString());
>   }
>   private Random  rand  = new Random();
>   private String getRandomString() {
>     StringBuilder sb  = new StringBuilder();
>     for (int i = Math.abs(rand.nextInt() % 16) + 1; i-- > 0; )
>       sb.append(ALPHABET.charAt(Math.abs(rand.nextInt() % ALPHABET.length())));
>     return sb.toString();
>   }
>   public static void main(String[] argv) {
>     if (argv.length > 0) {
>       try {
>         new TestDrools(Integer.parseInt(argv[0])).run();
>       }
>       catch (Exception ex) {
>         ex.printStackTrace();
>       }
>     }
>     else
>       System.out.println("Usage: TestDrool [# of packages]");
>   }
> }
> package test;
> /**
>  * Created by IntelliJ IDEA. User: SG0521861 Date: Aug 2, 2007 Time: 3:38:13 PM To change this template use File |
>  * Settings | File Templates.
>  */
> public class TestObject {
>   private String  value1;
>   private String  value2;
>   private String  result;
>   public String getValue1()             { return value1; }
>   public void setValue1(String value1)  { this.value1 = value1; }
>   public String getValue2()             { return value2; }
>   public void setValue2(String value2)  { this.value2 = value2; }
>   public String getResult()             { return result; }
>   public void setResult(String result)  { this.result = 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 lists.jboss.org  Thu Aug 16 16:35:13 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Thu, 16 Aug 2007 16:35:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1041) jBPM documentation
 changes to include Deployment and Debug steps.
In-Reply-To: <21593965.1187275262652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23444661.1187296513678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1041?page=all ]

Ronald van Kuijk closed JBPM-1041.
----------------------------------

    Resolution: Incomplete Description

> jBPM documentation changes to include Deployment and Debug steps.
> -----------------------------------------------------------------
>
>                 Key: JBPM-1041
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1041
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Documentation
>    Affects Versions: jBPM GPD 3.0.7
>         Environment: All
>            Reporter: Satya Satyamoorthy
>         Assigned To: Tom Baeyens
>             Fix For: jBPM GPD 3.0.7
>
>
> Please add adequate documentation listing the steps to 
> 1. Deploy the processes to different environments - such as test, user acceptance, production etc. from the RHDS.
> 2. Set breakpoints and Trace and 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 lists.jboss.org  Thu Aug 16 16:39:01 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Thu, 16 Aug 2007 16:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19041553.1187296741215.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372645 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

Ronald,  
I can't take the time to read them closely enough to respond accurately.
They certainly are close, but close doesn't count.
Does JobExecutorDbTest fail in the same way?
I don't see any reference to it in any JIRA reports, so if it is failing, I'd reference it on this report, rather than close the report.
-Ed


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 16:51:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 16 Aug 2007 16:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-449) maven-jbossaop-plugin
 cannot manage multiple aoppath
In-Reply-To: <16528869.1185623807145.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13827960.1187297461824.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-449?page=all ]

Anders Andersen closed JBAOP-449.
---------------------------------


I have testet the change
and now no aoppath will generate a default with correct file path.


> maven-jbossaop-plugin cannot manage multiple aoppath
> ----------------------------------------------------
>
>                 Key: JBAOP-449
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-449
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> I am trying to convert jboss portal to maven2
> Using the plugin maven-jbossaop-plugin seems to lack functionality
> In the ant script it is called
>        <aopc  compilerclasspathref="aop.classpath" verbose="true">
>           <classpath refid="bilto"/>
>          <src path="${build.classes}"/>
>           <aoppath path="${build.resources}/portal-core-sar/portal-aop.xml"/>
>           <aoppath path="${source.etc}/jboss-aop/base-aop.xml"/>
>           <include name="org/jboss/portal/core/aspects/server/TransactionInterceptor.class"/>
>           <include name="org/jboss/portal/core/aspects/server/UserInterceptor$UserFinalizer.class"/>
>           <include name="org/jboss/portal/core/aspects/portlet/TransactionInterceptor.class"/>         
>           <include name="org/jboss/portal/core/deployment/jboss/ObjectDeployment.class"/>
>           <include name="org/jboss/portal/core/deployment/jboss/PortletAppDeployment.class"/>
>           <include name="org/jboss/portal/core/impl/model/instance/InstanceContainerImpl.class"/>
>           <include name="org/jboss/portal/core/impl/model/portal/PersistentPortalObjectContainer.class"/>
>           <include name="org/jboss/portal/core/impl/portlet/state/ProducerPortletInvoker.class"/>
>           <include name="org/jboss/portal/core/hibernate/SessionFactoryBinder.class"/>
>        </aopc>
> in the plugin multiple aoppath  will not be accepted.
> I have tried to give two xml files with "" ; , or : as seperator --> without 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 lists.jboss.org  Thu Aug 16 17:02:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 16 Aug 2007 17:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7960769.1187298121436.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-453?page=all ]

Anders Andersen reopened JBAOP-453:
-----------------------------------

             
I have testet this changes as well.
I have moved all AOP dependencies away and it works !!!!!!!
VERY BEAUTIFUL!!!!

But it did not work for me, because the compiler classpath needs to know the dependency list as well.

When I add code
      for(Object one : project.getDependencyArtifacts()) {
         Artifact a=(Artifact)one;
          sb.append(a.getFile().toString()).append(File.pathSeparator);
      }
to the createClassPathList() it works for me.
I do understand that AOPC must know the dependent artifacts, because it can get factories, classes, log-classes or what ever the AOP uses from here.

   private String createClassPathList()
   {
      StringBuffer sb = new StringBuffer();
      for(Artifact a : pluginArtifacts)
      {
         sb.append(a.getFile().toString()).append(File.pathSeparator);
      }
      for(Object one : project.getDependencyArtifacts()) {
         Artifact a=(Artifact)one;
          sb.append(a.getFile().toString()).append(File.pathSeparator);
      }

      if(isTest())
         sb.append(project.getBuild().getTestOutputDirectory());
      else
         sb.append(project.getBuild().getOutputDirectory());

      return sb.toString();
   }


> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug 16 17:08:11 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 17:08:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2443385.1187298491179.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372657 ] 
            
Thomas Heute commented on JBPORTAL-1631:
----------------------------------------

Note that this solution doesn't aim at only solving the CSS compatibility issues but the different kind of browsers.

a) It's actually very easy to have a wrong behavior, try to install IE 5 and IE 6 on a same machine, both will be seen as the latest version you install (i guess it takes it from the windows registry) and the conditonal statement will be fooled. The idea of changing the user-agent is usally to fool the server to avoid some display problem. let's say you get a new for of Netscape called MyGreatBrowser, and the server is trying to send a IE CSS because it doesn't know about this new browser, then the client still has a way to "force" the Netscape stylesheet, it's a feature.

The code-like stuff i was talking about should be for all the different themes (actually it should also have a way to define no CSS for some themes on some browsers (maybe you will only have 2 themes for the Opera on the Nintendo Wii, but 10 for traditional browsers)

My example about IE8 was to say that if IE8 stop supporting this or do it in another way, you would end up with the same problem as of today, you couldn't define a special CSS for IE8.

The additional processing is really cheap, 1 parsing per session is something we can offer. (We can also argue that the other browsers also have to parse this conditional statement to ignore it).

Anyway, i am not against supporting the conditional statement, but i didn't see a little change that would make it work (i didn't look very hard). So if we need to do extra work, let's do it the good way, even more since we are re-designing the whole theme/layout support for next major versions.

Too bad for the CSS compiler :) JBoss CSS Compiler sounded like a good project name :-D 

Thanks for your input, don't think i'm just against the idea, i'm trying to get the best from the original idea. I totally agree that not supporting this is a major problem for IE versions. (more than any other browser)

> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 17:10:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Thu, 16 Aug 2007 17:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31791695.1187298601162.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372658 ] 
            
Jeff Johnson commented on JBPM-1042:
------------------------------------

I used jobExecutorDbTest as the starting point to the test case.  I plagarized heavily. 
The changes are:
1. Only creates one process instances.  Eliminates the issues associated with multiple job executor threads running.  You can change nbrOfThreads to 1 and still get the same behavior. I don't this this failure has anything to do with mulitiple job executor threads or hibernate session issues.
2. The process definition is simpler. It only contains a start node, node1, node2, and end  node.

My biased, novice opinion FWIW: Leave it open. It is slightly different test case, perhaps simpler case. Based on my review of the discussions and the JIRA reports, I think there are multiple issues that interact with each other. I tried to create a test case that isolates one specific problem. With luck solving this problem might make some of the other things more deterministic and simpler to debug. 

Looks like Node.execute(ExecutionContext context) change noticeable from 3.2GA (which I haven't used)
Just a little more detail.
In 3.2.1 Node.execute() calls org.jbpm.graph.def.GraphElement.executeAction().  This is the code that locks the token and then actually makes the call to action.execute().  Notice that the lock isn't unlocked until the finally block.  
// GraphElement
public void executeAction(Action action, ExecutionContext executionContext) {
    Token token = executionContext.getToken();

    // create action log
    ActionLog actionLog = new ActionLog(action);
    token.startCompositeLog(actionLog);

    try {
      // update the execution context
      executionContext.setAction(action);

      // execute the action
      log.debug("executing action '"+action+"'");
      String lockOwnerId = "token["+token.getId()+"]"; 
      try {
        token.lock(lockOwnerId);   // THIS IS WERE IT GETS LOCKED
        
        if (UserCodeInterceptorConfig.userCodeInterceptor!=null) {
          UserCodeInterceptorConfig.userCodeInterceptor.executeAction(action, executionContext);
        } else {
          action.execute(executionContext);
        }

      } finally {
        token.unlock(lockOwnerId);
      }
   
    } catch (Exception exception) {
      // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
      log.error("action threw exception: "+exception.getMessage(), exception);
      
      // log the action exception 
      actionLog.setException(exception);
   
      // if an exception handler is available
      raiseException(exception, executionContext);
      
    } finally {
      executionContext.setAction(null);
      token.endCompositeLog();
    }
  }

The problem comes in Node.enter() in the fragment below.  

   // execute the node
    if (isAsync) {
      ExecuteNodeJob job = createAsyncContinuationJob(token);
      MessageService messageService = (MessageService) 
             Services.getCurrentService(Services.SERVICENAME_MESSAGE);
      messageService.send(job);
      token.lock(job.toString());    //####  OOPS! THE TOKEN IS ALREADY LOCKED! #####
    } else {
      execute(executionContext);
    }
 

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 17:29:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 16 Aug 2007 17:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
Message-ID: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>

NodeNotExistException with concurent put/remove operations
----------------------------------------------------------

                 Key: JBCACHE-1164
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
    Affects Versions: 1.4.1.SP4
         Environment: Windows XP, Sun jdk150_06 
            Reporter: Jacek Halat
         Assigned To: Jason T. Greene


When 2 Threads are putting/removing data from this same node, put operation fails with exception

org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
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:89) 
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) 
(...) 

Thread 1 is calling: 
	cache.remove("/a/b/c/d");
	cache.remove("/a");
 Thread 2 is calling: 
	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Thu Aug 16 17:31:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 16 Aug 2007 17:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
In-Reply-To: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5197496.1187299861186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1164?page=all ]

Jacek Halat updated JBCACHE-1164:
---------------------------------

    Attachment: ConcurentOperationsTest.java

TestCase ilustrating this bug.

> NodeNotExistException with concurent put/remove operations
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1164
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: ConcurentOperationsTest.java
>
>
> When 2 Threads are putting/removing data from this same node, put operation fails with exception
> org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
> 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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
> 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:89) 
> 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) 
> (...) 
> Thread 1 is calling: 
> 	cache.remove("/a/b/c/d");
> 	cache.remove("/a");
>  Thread 2 is calling: 
> 	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Thu Aug 16 17:31:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Thu, 16 Aug 2007 17:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15145990.1187299861500.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372674 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Pleaze fix the dependency resolution by adding compile

* @requiresDependencyResolution compile 

otherwise we cannot scope dependencies to i.e. provided

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug 16 17:51:03 2007
From: jira-events at lists.jboss.org (Chris Rose (JIRA))
Date: Thu, 16 Aug 2007 17:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-69) Hibernate MBean
 not releasing
 connections per-statement despite default configuration
Message-ID: <500430.1187301063369.JavaMail.jira@cloud.prod.atl2.jboss.com>

Hibernate MBean not releasing connections per-statement despite default configuration
-------------------------------------------------------------------------------------

                 Key: HIBERNATE-69
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-69
             Project: Hibernate
          Issue Type: Bug
         Environment: JBoss AS 4.0.4 GA
Linux (Fedora core 5)
Oracle 9i
            Reporter: Chris Rose
         Assigned To: Steve Ebersole


When flushing the hibernate connection on a managed hibernate module (har file) I get the following warning:
15:32:23,879 INFO  [CachedConnectionManager] Closing a connection for you.  Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection at 16c5525
java.lang.Throwable: STACKTRACE

The stack trace (found below) indicates that this is occurring in the session.flush method which I call in order to read in my database's generated columns:
session.save(newObject);
session.flush ();
session.refresh (newObject);

This is in a session bean method with the transaction-type: required

The stack trace has another error after it that I am not sure is related to the initial problem, but might be; I attach it for completeness, if nothing else.

Stacktrace follows:
15:32:23,879 INFO  [CachedConnectionManager] Closing a connection for you.  Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection at 16c5525
java.lang.Throwable: STACKTRACE
	at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:290)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:400)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:812)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
	at org.hibernate.connection.DatasourceConnectionProvider.getConnection(DatasourceConnectionProvider.java:69)
	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:417)
	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
	at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:94)
	at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
	at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:218)
	at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2106)
	at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2503)
	at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51)
	at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:993)
	at com.aciworldwide.ecourier.management.ejb.OperationsManagerSessionBean.updateUser(OperationsManagerSessionBean.java:1323)
	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.invocation.Invocation.performCall(Invocation.java:359)
	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
	at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:64)
	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:350)
	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.SessionContainer.internalInvoke(SessionContainer.java:648)
	at org.jboss.ejb.Container.invoke(Container.java:954)
	at sun.reflect.GeneratedMethodAccessor190.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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
	at sun.reflect.GeneratedMethodAccessor189.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:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)
15:32:23,923 INFO  [ConnectionManager] forcing batcher resource cleanup on transaction completion; forgot to close ScrollableResults/Iterator?
15:32:23,923 WARN  [AbstractBatcher] Could not close a JDBC result set
java.sql.SQLException: Already closed
	at org.jboss.resource.adapter.jdbc.WrappedResultSet.close(WrappedResultSet.java:178)
	at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:310)
	at org.hibernate.jdbc.ConnectionManager.afterTransaction(ConnectionManager.java:291)
	at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:214)
	at org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85)
	at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1526)
	at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1198)
	at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:413)
	at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:493)
	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361)
	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.SessionContainer.internalInvoke(SessionContainer.java:648)
	at org.jboss.ejb.Container.invoke(Container.java:954)
	at sun.reflect.GeneratedMethodAccessor190.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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
	at sun.reflect.GeneratedMethodAccessor189.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:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:595)

jboss-service.xml for the har file:
<?xml version="1.0" encoding="UTF-8"?>
<mbean code="org.jboss.hibernate.jmx.Hibernate" name="jboss.har:service=ecdb-cralphaiss-Hibernate">
  <attribute name="DatasourceName">java:ecourier-cralphaissDS</attribute>
  <attribute name="SessionFactoryName">java:ecourier-ecdb-cralphaiss-SessionFactory</attribute>
  <attribute name="Dialect">org.hibernate.dialect.Oracle9Dialect</attribute>
  <attribute name="CacheProviderClass">org.hibernate.cache.HashtableCacheProvider</attribute>
  <attribute name="ScanForMappingsEnabled">false</attribute>
  <attribute name="ShowSqlEnabled">true</attribute>
</mbean>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 18:07:01 2007
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Aug 2007 18:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4422)
 org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
In-Reply-To: <18432255.1179272695652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32198226.1187302021082.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4422?page=all ]

Richard Achmatowicz closed JBAS-4422.
-------------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                   JBossAS-4.2.2.GA
       Resolution: Done
         Assignee: Richard Achmatowicz  (was: Stan Silvert)

Tested the change on RHEL 5 and Windows. 
Committed the change to 
svn.jboss.org:/repos/jbossas/branches/JBPAPP_4_2_0_GA_CP 
svn.jboss.org:/repos/jbossas/branches/Branch_4_2 
svn.jboss.org:/repos/jbossas/trunk


> org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host
> ------------------------------------------------------------------
>
>                 Key: JBAS-4422
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4422
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.0.CR2
>         Environment: x86, Windows 2003 , Sun and BEA JVM 
>            Reporter: Richard Achmatowicz
>         Assigned To: Richard Achmatowicz
>            Priority: Trivial
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. 
> The command line built when executing on Windows is: 
> > cmd /C twiddle get "jboss.system:type=Server" "Started" 
> and the response should be 
> "Started=true" 
> It appears that twiddle had an option for specifying the server host, but this option has been commented out. 
> When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 
> 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available 
> and the test fails. 
> (please see the linked issue JBPAPP-176 for more 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 lists.jboss.org  Thu Aug 16 18:11:20 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 18:11:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1627) Problem
 destroying service
 portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
In-Reply-To: <12607797.1186753680992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13573574.1187302280164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1627?page=all ]

Thomas Heute resolved JBPORTAL-1627.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

Thanks a lot Roman for this patch !

> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> ------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1627
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1627
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: JBPORTAL-1627.patch
>
>
> On AS shutdown:
> Problem destroying service portal:service=ContentRenderer,type=GoogleWidgetPortletInstance
> java.lang.reflect.UndeclaredThrowableException
>         at $Proxy0.destroy(Unknown Source)
>         at org.jboss.system.ServiceController.destroy(ServiceController.java:577)
>         at org.jboss.system.ServiceController.shutdown(ServiceController.java:714)
>         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.server.ServerImpl$ShutdownHook.shutdownServices(ServerImpl.java:1079)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1037)
>         at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
> Caused by: javax.management.InstanceNotFoundException: portal:service=ContentRenderer,type=GoogleWidgetPortletInstance is not registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:653)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
>         ... 15 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 lists.jboss.org  Thu Aug 16 18:38:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 16 Aug 2007 18:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-1608) CMS content type
 always display with no decoration
In-Reply-To: <3650382.1185258947112.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2170054.1187303881078.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1608?page=all ]

Thomas Heute closed JBPORTAL-1608.
----------------------------------


> CMS content type always display with no decoration
> --------------------------------------------------
>
>                 Key: JBPORTAL-1608
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1608
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Changing window properties has no 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 lists.jboss.org  Thu Aug 16 18:51:01 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 16 Aug 2007 18:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32939928.1187304661192.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372685 ] 
            
Stale Pedersen commented on JBAOP-453:
--------------------------------------

i added the dependency resolution, but i dont understand why we need to append project dependant artifacts to the classpath. if you use the plugin and want to add dependencies to it you can just add them in the plugin configuration and they will be added from there. see paul's comment at 9 aug. - or am i missing something?

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Thu Aug 16 20:17:01 2007
From: jira-events at lists.jboss.org (Jeff DeLong (JIRA))
Date: Thu, 16 Aug 2007 20:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1097) Manual
 html_single does not have TOC entry for Chapter 9 BRMS
Message-ID: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>

Manual html_single does not have TOC entry for Chapter 9 BRMS
-------------------------------------------------------------

                 Key: JBRULES-1097
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions:  4.0.0.GA
            Reporter: Jeff DeLong
         Assigned To: Mark Proctor
             Fix For: 4.0.1


Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 20:19:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 16 Aug 2007 20:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1097) Manual
 html_single does not have TOC entry for Chapter 9 BRMS
In-Reply-To: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6269503.1187309941187.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1097?page=all ]

Michael Neale reassigned JBRULES-1097:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Manual html_single does not have TOC entry for Chapter 9 BRMS
> -------------------------------------------------------------
>
>                 Key: JBRULES-1097
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Jeff DeLong
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 16 22:51:01 2007
From: jira-events at lists.jboss.org (Andy Pemberton (JIRA))
Date: Thu, 16 Aug 2007 22:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1631) Allow
 different stylesheets for different user-agents
In-Reply-To: <15301349.1187184661124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4438335.1187319061257.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1631?page=comments#action_12372694 ] 
            
Andy Pemberton commented on JBPORTAL-1631:
------------------------------------------

Sounds good; thanks for the quick feed back. Your solution would definitely solve the issue our client is having and I look forward to using JBoss Portal 2.8.

> Allow different stylesheets for different user-agents
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1631
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1631
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Thomas Heute
>         Assigned To: Julien Viet
>             Fix For: 2.8 Final
>
>
> It should be possible to define several stylesheets for a theme that would be applied for different user-agents.
> Several stylesheets can be handy to respect the differences between IE versions and also with other browsers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 03:34:17 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 03:34:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1165) Endless loop in
 PessimisticLockInterceptor
Message-ID: <14669904.1187336057521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Endless loop in PessimisticLockInterceptor
------------------------------------------

                 Key: JBCACHE-1165
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.1.SP4
         Environment: Windows XP, Sun jdk150_06 
Solaris 10
            Reporter: Jacek Halat
         Assigned To: Manik Surtani


When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop.
Main loop looks like:
				for (int x = 0; x < 1000; x++) {
					tm.begin();
					System.out.println("R" + Thread.currentThread().getName());
					//inside transaction
					cache.remove("/a");
					System.out.println("AR" + Thread.currentThread().getName());
					tm.commit();
					//outside transaction
					System.out.println("P" + Thread.currentThread().getName());
					cache.put("/a/b/c/d", "text"+x,"b");
					System.out.println("AP" + Thread.currentThread().getName());
				}



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 03:38:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 03:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1165) Endless loop in
 PessimisticLockInterceptor
In-Reply-To: <14669904.1187336057521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19001128.1187336281161.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1165?page=all ]

Jacek Halat updated JBCACHE-1165:
---------------------------------

    Attachment: ConcurentPutRemoveTest.java
                ConsoleOut.log

JUnit test to this issue.
This test sometimes finish with success, sometimes fails with NodeNotExistException and sometimes goes into infinitive loop.

Attached ConsoleOutput with ThreadDumps when test goes into infinivie loop.

> Endless loop in PessimisticLockInterceptor
> ------------------------------------------
>
>                 Key: JBCACHE-1165
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>         Attachments: ConcurentPutRemoveTest.java, ConsoleOut.log
>
>
> When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop.
> Main loop looks like:
> 				for (int x = 0; x < 1000; x++) {
> 					tm.begin();
> 					System.out.println("R" + Thread.currentThread().getName());
> 					//inside transaction
> 					cache.remove("/a");
> 					System.out.println("AR" + Thread.currentThread().getName());
> 					tm.commit();
> 					//outside transaction
> 					System.out.println("P" + Thread.currentThread().getName());
> 					cache.put("/a/b/c/d", "text"+x,"b");
> 					System.out.println("AP" + Thread.currentThread().getName());
> 				}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 04:14:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 04:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
Message-ID: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>

UpgradeException on concurent put/remove operation
--------------------------------------------------

                 Key: JBCACHE-1166
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
         Environment: Windows XP, Sun jdk150_06 
            Reporter: Jacek Halat
         Assigned To: Manik Surtani
         Attachments: ConcurentOperationTest.java

When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock

Full StackTrace:
org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
	... 5 more
Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
	... 25 more
Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
	... 27 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 lists.jboss.org  Fri Aug 17 04:14:01 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Fri, 17 Aug 2007 04:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29018335.1187338441752.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=all ]

Jacek Halat updated JBCACHE-1166:
---------------------------------

    Attachment: ConcurentOperationTest.java

JUnit test to this issue

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>         Attachments: ConcurentOperationTest.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Fri Aug 17 04:31:01 2007
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Fri, 17 Aug 2007 04:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7131093.1187339461189.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Tom Baeyens updated JBPM-1042:
------------------------------

    Attachment: jbpm-jpdl.jar

can you guys check out the attached patched jbpm-jpdl.jar file.  does that resolve this problem for you ?

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 04:49:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 04:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1041) jBPM documentation
 changes to include Deployment and Debug steps.
In-Reply-To: <21593965.1187275262652.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27092563.1187340541231.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1041?page=comments#action_12372717 ] 
            
Ronald van Kuijk commented on JBPM-1041:
----------------------------------------

hmmm I was sure I also added a comment... here we go

- old version of GPD, very old version
- GPD has it's own project in jira, called GPD: http://jira.jboss.com/jira/browse/GPD
- very little info
- different requests in one issue

Now more constructive answers

1: totally up to you. use the console, create/use ant tasks, create you own app... pick one...if you want different deployment methods between test and production, then do so.. if not, keep them the same.

2: Runtime at the 'process' level? e.g. when a certain task is encountered? then file a jira issue for the GPD. This is *not* just a documentation  issue but a very complex thing to build. You can do this in unit tests very easily btw...

> jBPM documentation changes to include Deployment and Debug steps.
> -----------------------------------------------------------------
>
>                 Key: JBPM-1041
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1041
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Documentation
>    Affects Versions: jBPM GPD 3.0.7
>         Environment: All
>            Reporter: Satya Satyamoorthy
>         Assigned To: Tom Baeyens
>             Fix For: jBPM GPD 3.0.7
>
>
> Please add adequate documentation listing the steps to 
> 1. Deploy the processes to different environments - such as test, user acceptance, production etc. from the RHDS.
> 2. Set breakpoints and Trace and 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 lists.jboss.org  Fri Aug 17 05:32:01 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Fri, 17 Aug 2007 05:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-150) In-place label edit
 box offset in scrolled editor
Message-ID: <33534539.1187343121259.JavaMail.jira@cloud.prod.atl2.jboss.com>

In-place label edit box offset in scrolled editor
-------------------------------------------------

                 Key: GPD-150
                 URL: http://jira.jboss.com/jira/browse/GPD-150
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
            Reporter: David Good
         Assigned To: Koen Aers
            Priority: Minor


When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position (see attachment)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:37:01 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Fri, 17 Aug 2007 05:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-150) In-place label edit
 box offset in scrolled editor
In-Reply-To: <33534539.1187343121259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25441816.1187343421363.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-150?page=all ]

David Good updated GPD-150:
---------------------------

    Attachment: screenshot-1.jpg

> In-place label edit box offset in scrolled editor
> -------------------------------------------------
>
>                 Key: GPD-150
>                 URL: http://jira.jboss.com/jira/browse/GPD-150
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
>            Reporter: David Good
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: screenshot-1.jpg
>
>
> When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position (see attachment)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:37:01 2007
From: jira-events at lists.jboss.org (David Good (JIRA))
Date: Fri, 17 Aug 2007 05:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-150) In-place label edit
 box offset in scrolled editor
In-Reply-To: <33534539.1187343121259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30117942.1187343421677.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-150?page=all ]

David Good updated GPD-150:
---------------------------

    Description: When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position if the scroll bars are not in the origin. (see attachment)  (was: When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position (see attachment))

> In-place label edit box offset in scrolled editor
> -------------------------------------------------
>
>                 Key: GPD-150
>                 URL: http://jira.jboss.com/jira/browse/GPD-150
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM JPDL Designer 3.1.0.CR
>         Environment: Eclipse 3.3, Windows XP SP2, JDK 6
>            Reporter: David Good
>         Assigned To: Koen Aers
>            Priority: Minor
>         Attachments: screenshot-1.jpg
>
>
> When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position if the scroll bars are not in the origin. (see attachment)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:51:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 05:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-983) concurrent process
 execution fails
In-Reply-To: <30055235.1181555411656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20311897.1187344262314.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-983?page=comments#action_12372722 ] 
            
Ronald van Kuijk commented on JBPM-983:
---------------------------------------

the issue in JBPM-1042 is one of the errors I encountered during testing the above cases.  So look there for some more info

> concurrent process execution fails
> ----------------------------------
>
>                 Key: JBPM-983
>                 URL: http://jira.jboss.com/jira/browse/JBPM-983
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>         Environment: Hypersonic in-memory database, JobExecutor configured with 5 threads
>            Reporter: Alexander Schlett
>         Assigned To: Tom Baeyens
>            Priority: Critical
>             Fix For: jBPM 3.3
>
>         Attachments: SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java, SimpleTest.java
>
>
> concurrent execution of async nodes with multiple JobExecutor threads fails. the effect is:
> 1) job sync within JobExecutor fails due to org.hibernate.StaleObjectStateException
> 2) process gets stuck in join node and never ends
> junit test for this is attached, it's a simple process with just a fork and a join and some scripts inbetween.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 05:51:02 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 05:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1744744.1187344262762.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372723 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

Ed, 

You are correct in pointing me to your limited amount of time. I already respect you a lot for the time you *do* invest. 

You are also correct in pointing out that this error is not mentioned in one of the other issues. It did occur there when I was investigating. Mea culpa. 

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 07:53:01 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 17 Aug 2007 07:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-454) Upgrade jboss retro
	to 1.1.2
Message-ID: <31251926.1187351581112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss retro to 1.1.2
----------------------------

                 Key: JBAOP-454
                 URL: http://jira.jboss.com/jira/browse/JBAOP-454
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Flavia Rainone
             Fix For: 2.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 lists.jboss.org  Fri Aug 17 08:11:08 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:11:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1633) Build new
	identity portlets
Message-ID: <20557023.1187352668315.JavaMail.jira@cloud.prod.atl2.jboss.com>

Build new identity portlets
---------------------------

                 Key: JBPORTAL-1633
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1633
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


Building new identity portlets.

1 for users
1 for managing users and 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 lists.jboss.org  Fri Aug 17 08:11:08 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:11:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1634) Finish the user
 email
 verification after registration and when a user change his email
Message-ID: <21470014.1187352668490.JavaMail.jira@cloud.prod.atl2.jboss.com>

Finish the user email verification after registration and when a user change his email 
---------------------------------------------------------------------------------------

                 Key: JBPORTAL-1634
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1634
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:11:08 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:11:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1635) Lost password
 feature, attribute a random password and send it by email
Message-ID: <26661164.1187352668657.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lost password feature, attribute a random password and send it by email 
------------------------------------------------------------------------

                 Key: JBPORTAL-1635
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1635
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:13:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1636) Captcha support
 (with jcpatcha probably)
Message-ID: <32032096.1187352781527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Captcha support (with jcpatcha probably) 
-----------------------------------------

                 Key: JBPORTAL-1636
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1636
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:13:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1637) XML
 configuration of user properties
Message-ID: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>

XML configuration of user properties
------------------------------------

                 Key: JBPORTAL-1637
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


 parsed with 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 lists.jboss.org  Fri Aug 17 08:13:02 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1638) Modify "edit
 profile" to let modification of email and password
Message-ID: <8183870.1187352782096.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify "edit profile" to let modification of email and password 
----------------------------------------------------------------

                 Key: JBPORTAL-1638
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1638
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:15:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1639) Let the
 administrator enable or disable a user
Message-ID: <17294032.1187352901536.JavaMail.jira@cloud.prod.atl2.jboss.com>

Let the administrator enable or disable a user 
-----------------------------------------------

                 Key: JBPORTAL-1639
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1639
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 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 lists.jboss.org  Fri Aug 17 08:38:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 08:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10356527.1187354281562.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372733 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

Actually its already parsed. You can obtain list of user properties from the profile

UserProfileModule.getProfileInfo.getPropertiesInfo()

returns a Map o PropertyInfo objects that describe configured user properties. So you only need to render proper view based on that info

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:40:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 08:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17183608.1187354401580.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372734 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

also you should check PropertyInfo.getAccessMode() to check for read-only props.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:44:10 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27746881.1187354650634.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372738 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

There is a need for other metadata like:
mandatory or not...
input text, checkbox ? If we want to build the JSF page dynamically (not at first, not sure we will even do it)

I actually wondered what the identity XML is all about in the current case.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:48:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8992485.1187354881498.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372739 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

"Mandatory" and "type" are already there :)

Nice.

Why is it used today ? Does the user portlet check this ?

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:50:06 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 08:50:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <38752.1187355006155.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372741 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

Yes everything is there, and what's missing could be added, we would need stuff like:

Should appear at registration
Should appear in the user profile

Somehow i thought it was only used for database.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 08:54:03 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 08:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31887036.1187355243363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372743 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

most of them are not used right now (it was actually added having dynamic jsp page creation in mind ;)). I have also other ones on plate for 2.8 related to profile
http://jira.jboss.com/jira/browse/JBPORTAL-1493
http://jira.jboss.com/jira/browse/JBPORTAL-1494

I'm open for all the suggestions as I don't know all the use cases from UI point of view.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 09:05:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11509192.1187355901354.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372744 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

Ok then we will just add another config-file in core-identity for pure UI stuff like the one i mentionned and map on the property name.

Thanks a lot for your comments !

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 10:30:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 17 Aug 2007 10:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1047) class Cast
 Exception when using OR (||)
In-Reply-To: <20755281.1185814069735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20447200.1187361001258.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1047?page=comments#action_12372753 ] 
            
Edson Tirelli commented on JBRULES-1047:
----------------------------------------

I added parser tests, but parsing is being correctly handled.

Can you please show us any rules you have in the same rule base that are using an "eval()" statement that does any check on a Relation object?

The problem may happen because of this rule, but is being triggered by a rule that contains an eval().

Thanks.

> class Cast Exception when using OR (||)
> ---------------------------------------
>
>                 Key: JBRULES-1047
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1047
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows, X86
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> When I define a rule:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct, 
>                active:active==$1,
>                relationName=="Old")
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ..The bove works. 
> BUT, when I do the following:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> || Relation( contact==cntct, 
>                active:active==$1,
>                relationName==null)
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ... The script compiles anda stateless Session is created successfully, 
> but at 
> runtime/execution it fails with the exception:
> java.lang.ClassCastException: com.arjun.brms.businessObjects.Contact
> org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:75)
> org.drools.reteoo.EvalConditionNode.assertTuple (EvalConditionNode.java:141)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple 
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:317)
> org.drools.reteoo.AlphaNode.assertObject (AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject 
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> org.drools.reteoo.Rete.assertObject(Rete.java:168)
> org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java :190)
> org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java :822)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> Class diagram:
> ~~~~~~~~~~~~~~~~
> Contact<-- bi-directional association -->List<Relation>
> =============================================================================
> Edson comments (Response) :
> -----------------------------------------
> It is a bug since a more friendly message should be raised at compile time stating that your "contact" declaration is not available in one of your logical branches. 
>     Having said that, what you want to do is make your OR take priority over the implicit AND and as such, you need to add () around the OR: 
> When
> contact:Contact (initialized==true)
> exr: ( Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> or Relation( contact==cntct,
>                active:active==$1, 
>                relationName==null) )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    Having said that, better yet for you would not to use the OR CE, but to use restriction connectives. This would be the most efficient (and clean) way of writing your rule: 
> When
> contact:Contact (initialized==true)
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName =="Old" || == null )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    As a syntax sugar, you could also write:
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName in ( "Old", null ) )
>    Can you please open a JIRA with your test case for the bug? 
>    Thank you,
>         Edson
> -------------------
> Note: The above suggestion worked, no runtime errors with 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 lists.jboss.org  Fri Aug 17 10:38:30 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 17 Aug 2007 10:38:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-397) Add better error
 handling to
 retro when an attempt is made to retro the same class twice.
Message-ID: <26091371.1187361510411.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add better error handling to retro when an attempt is made to retro the same class twice.
-----------------------------------------------------------------------------------------

                 Key: JBBUILD-397
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-397
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.2.GA


If the same class is weaved twice, jboss-retro gives an error that the class is frozen and pruned.  Retro should check at the beginning of the process to see if there are any classes that will be weaved twice, and then give an error describing that one of them should 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 lists.jboss.org  Fri Aug 17 10:38:30 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 17 Aug 2007 10:38:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-397) Add better error
 handling to
 retro when an attempt is made to retro the same class twice.
In-Reply-To: <26091371.1187361510411.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28424591.1187361510556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-397?page=all ]

Paul Gier updated JBBUILD-397:
------------------------------

     Original Estimate: 1 day
    Remaining Estimate: 1 day

> Add better error handling to retro when an attempt is made to retro the same class twice.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-397
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-397
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.1.2.GA
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> If the same class is weaved twice, jboss-retro gives an error that the class is frozen and pruned.  Retro should check at the beginning of the process to see if there are any classes that will be weaved twice, and then give an error describing that one of them should 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 lists.jboss.org  Fri Aug 17 10:48:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 10:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26507771.1187362081578.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372757 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

If you want to have separate config for UserPortlet I should probably move some of those options to your file because it'll be doubled. But when I think about it....
2 separate files with similar content - a list of properties but with different parameters... looks like a config nightmare to me :)
So to add remove a property you need to put that info into two files. Maybe it would be better to workout common list of meta-data describing user property and extend current property-info.xml. The nature of the API is that its easy to extend and difficult to remove :)

The question is: What does it buy us to have separate configuration for UserPortlet for stuff that can be gathered from existing metadata.

There will be changes in identity in 2.8 but for this part it should be rather evolution than revolution.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 11:25:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 11:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1592) Backslashes
 not escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8303953.1187364301690.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=comments#action_12372764 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1592:
-----------------------------------------------

At first sorry I was not responding on this. I was off for some time and working on other stuff. 

To be honest I'm little confused about whats working and whats not. Are we talking about what kind of filter and where? Like I posted in forums if I put <value><![CDATA[(&(cn={0})(member=uid=jduke\\\, Duke,ou=People,o=test,dc=portal,dc=example,dc=com))]]></value> in identity-config.xml it works. So I understand that 3 backslashes are proper solution for filter placed there. 

Now for roles resolution I also was able to have it working with ldif I posted in forums. ("member: uid=jduke\, Duke,ou=People,o=test,dc=portal,dc=example,dc=com"). So roles resolution works ok with "strange" user names.

I'm not sure I understand properly what you wrote. 

"The filter is constructed by the code, one would not directly add LastName, FirstName for a filter, or only that specific user would be found."

So are we talking about filter in identity-config.xml or something in code? Mine or yours? :) Sory but this thread is little to long and hard to follow. Could you provide a real testcase for this? Like a short ldif + identity-config.xml I could play with. I'm not sure we are talking about the same things.


> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Fri Aug 17 11:37:01 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 17 Aug 2007 11:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29216831.1187365021638.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372766 ] 
            
Thomas Heute commented on JBPORTAL-1637:
----------------------------------------

The idea is to extend what you have not double anything (except the key for mapping purpose)

But adding metadata info about UI specific stuff doesn't really belong to the identity service. So it shouldn't be read (it should be ignored) by the identity service.

In one place you define your properties, with read-write, mandatory or not... And in the other place you define if it should appear, where, in what color (i made this up) and so on...



> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 11:48:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Fri, 17 Aug 2007 11:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1637) XML
 configuration of user properties
In-Reply-To: <15564527.1187352781842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20274960.1187365681719.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1637?page=comments#action_12372768 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1637:
-----------------------------------------------

ok.... <should_property_name_blink_when_mouse_is_over> won't be the best tag to place in profile-config.xml indeed :) 

If you think that some of the current metadata should be rather placed in UI configuration, or you have something in mind that should be add to identity metadata let me know.

> XML configuration of user properties
> ------------------------------------
>
>                 Key: JBPORTAL-1637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1637
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
>  parsed with 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 lists.jboss.org  Fri Aug 17 12:32:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 17 Aug 2007 12:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4612) Non ignorable white
 space is ignored while read env-entries
Message-ID: <31277697.1187368321048.JavaMail.jira@cloud.prod.atl2.jboss.com>

Non ignorable white space is ignored while read env-entries
-----------------------------------------------------------

                 Key: JBAS-4612
                 URL: http://jira.jboss.com/jira/browse/JBAS-4612
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf
             Fix For:  JBossAS-5.0.0.Beta3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 12:42:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 17 Aug 2007 12:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4612) Non ignorable white
 space is ignored while read env-entries
In-Reply-To: <31277697.1187368321048.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15273757.1187368921440.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4612?page=all ]

Carlo de Wolf resolved JBAS-4612.
---------------------------------

    Resolution: Done

> Non ignorable white space is ignored while read env-entries
> -----------------------------------------------------------
>
>                 Key: JBAS-4612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4612
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 12:42:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 17 Aug 2007 12:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4612) Non ignorable white
 space is ignored while reading env-entries
In-Reply-To: <31277697.1187368321048.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8502406.1187368922155.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4612?page=all ]

Carlo de Wolf updated JBAS-4612:
--------------------------------

    Summary: Non ignorable white space is ignored while reading env-entries  (was: Non ignorable white space is ignored while read env-entries)

> Non ignorable white space is ignored while reading env-entries
> --------------------------------------------------------------
>
>                 Key: JBAS-4612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4612
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 14:27:01 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 17 Aug 2007 14:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
Message-ID: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>

runaway SLSB instance creation with ThreadLocalPool
---------------------------------------------------

                 Key: EJBTHREE-1031
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, AS 4.2.0 GA
            Reporter: William DeCoste
         Assigned To: William DeCoste


Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:16:01 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Fri, 17 Aug 2007 15:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8336866.1187378161715.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372797 ] 
            
Jeff Johnson commented on JBPM-1042:
------------------------------------

The unit test seems to work fine with the provided jar. I used the provided jar in a more complicated test involving multiple process instances with multiple async nodes and multiple job executor threads.  Everything I've done so far now works as expected.

Sorry for the novice question but how / when will this patch be made part of a release? Will there be a CVS tag that I can use to pull down 3.2.1 + this patch?  Or perhaps the modified sources can be provided until this gets in a release.   I just don't want build / deploy our system based on a jar for which I don't have source. (not to mention that I'm curious about the solution).

Thanks for all your help and the quick resolution!

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:51:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 15:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28597140.1187380261283.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372801 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

Solution came from http://jira.jboss.com/jira/browse/JBPM-995

Changeset checkins: http://fisheye.jboss.com/changelog/JBPM/jbpm.3/jpdl?cs=MAIN:tbaeyens:20070815123339 

But a little more was done... see http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl



> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:53:05 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 17 Aug 2007 15:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-1042)
 org.jbpm.JbpmException: token '1'
 can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10114856.1187380385196.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Ronald van Kuijk closed JBPM-1042.
----------------------------------

    Fix Version/s: jBPM jPDL 3.2.2
       Resolution: Done

Patches from JBPM-995 seem to solve this as wel. Reporter confirmed this, so closing

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 15:59:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 15:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-793) Lease should
 synchronize access to client map
Message-ID: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lease should synchronize access to client map
---------------------------------------------

                 Key: JBREM-793
                 URL: http://jira.jboss.com/jira/browse/JBREM-793
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.1.GA, 2.2.1.SP1, 2.2.0.SP4_CP02
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)


Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Fri Aug 17 16:11:01 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Fri, 17 Aug 2007 16:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28188350.1187381461198.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372809 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

Ronald,
Are you sure that's all Tom sent in the jar?  
I assumed he sent some work that was not yet checked in.
If it was checked in, I must misunderstand the problem, or I'm overlooking something in the checkins, because I don't see anything relevant to the specific problem.
-Ed


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 16:19:20 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 17 Aug 2007 16:19:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1032) inconsistent
 results for
 CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
Message-ID: <32360816.1187381960564.JavaMail.jira@cloud.prod.atl2.jboss.com>

inconsistent results for CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
-----------------------------------------------------------------------------------------

                 Key: EJBTHREE-1032
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1032
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1
            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 lists.jboss.org  Fri Aug 17 16:34:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 16:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12175378.1187382841103.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-783?page=comments#action_12372815 ] 
            
Ron Sigal commented on JBREM-783:
---------------------------------

The changes to org.jboss.remoting.MicroRemoteClientInvoker and org.jboss.remoting.LeasePinger introduced a race condition. Each PING sends the list of all current client leases, which is used to update the list of clients leases in org.jboss.remoting.Lease.  It is possible for one thread to send a PING with a client list from which a client lease has been removed and for that list to arrive before the server gets the request to terminate that lease.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.0.SP4_CP02, 2.2.1.SP1
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.1.SP1
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Fri Aug 17 18:58:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 17 Aug 2007 18:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1077) Decision tables
 to have ruleflow-group attribute column
In-Reply-To: <30015767.1186969861144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19887352.1187391481162.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1077?page=all ]

Fernando Meyer resolved JBRULES-1077.
-------------------------------------

    Resolution: Done

Added support for ruleflow group when column starts with R or is named RULEFLOW-GROUP 

> Decision tables to have ruleflow-group attribute column
> -------------------------------------------------------
>
>                 Key: JBRULES-1077
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1077
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Fernando Meyer
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> In decision tables, we can set no-loop attributes (amongst others) by haveing a special keyword in a column (chekc the code for how this is done). Would like to add ruleflow-group to this 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 lists.jboss.org  Fri Aug 17 20:07:01 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 17 Aug 2007 20:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1098) Add action
	support in ruleflow
Message-ID: <32055007.1187395621227.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add action support in ruleflow
------------------------------

                 Key: JBRULES-1098
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1098
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Rule Flow
            Reporter: Kris Verlaenen
         Assigned To: Kris Verlaenen
             Fix For: FUTURE


There should be an action node which simply executes the contained action when it is encountered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23480718.1187404261839.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-785?page=all ]

Ron Sigal updated JBREM-785:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.CR1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7729084.1187404261972.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-766?page=all ]

Ron Sigal updated JBREM-766:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s:     (was: 2.2.0.SP4_CP02)

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-761) NPE in
 BisocketServerInvoker$ControlConnectionThread
In-Reply-To: <9608977.1183001997620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18078601.1187404262089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-761?page=all ]

Ron Sigal updated JBREM-761:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> NPE in BisocketServerInvoker$ControlConnectionThread
> ----------------------------------------------------
>
>                 Key: JBREM-761
>                 URL: http://jira.jboss.com/jira/browse/JBREM-761
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> From Tim Fox:
> Here's one I saw today:
> @main 18:11:54,129 INFO  [FailoverTest] tearing down
> Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException
>        at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669)
> It seems pretty harmless, but nevertheless I thought I'd inform 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 lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-778)
 BisocketServerInvoker.start() creates a new static Timer each time
In-Reply-To: <3736496.1184968967071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15399209.1187404262358.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-778?page=all ]

Ron Sigal updated JBREM-778:
----------------------------

    Fix Version/s: 2.2.2.GA
                   2.4.0.CR1 (Pinto)
                       (was: 2.4.0.Beta1 (Pinto))
                       (was: 2.2.0.SP4_CP02)
                       (was: 2.2.1.SP1)

> BisocketServerInvoker.start() creates a new static Timer each time
> ------------------------------------------------------------------
>
>                 Key: JBREM-778
>                 URL: http://jira.jboss.com/jira/browse/JBREM-778
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start() creates a new static Timer each time.  It should only create a new Timer if (1) there is no existing Timer, or (2) the existing Timer has shut down.  See the similar issue JBREM-748.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4921951.1187404262637.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-787?page=all ]

Ron Sigal updated JBREM-787:
----------------------------

    Fix Version/s: 2.2.2.GA
                   2.4.0.CR1 (Pinto)
                       (was: 2.4.0.Beta1 (Pinto))
                       (was: 2.2.0.SP4_CP02)
                       (was: 2.2.1.SP1)

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16287270.1187404262790.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-783?page=all ]

Ron Sigal updated JBREM-783:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.1.GA
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.CR1 (Pinto)
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Fri Aug 17 22:31:02 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9463198.1187404262950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-790?page=all ]

Ron Sigal updated JBREM-790:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.4.0.Beta1 (Pinto)

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18888518.1187404263088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-782?page=all ]

Ron Sigal updated JBREM-782:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.2.1.SP1)
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.4.0.Beta1 (Pinto))
    Affects Version/s: 2.2.1.GA
                           (was: 2.2.1.SP1)
                           (was: 2.2.0.SP4_CP02)

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19824385.1187404263266.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-765?page=all ]

Ron Sigal updated JBREM-765:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31520097.1187404263518.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-788?page=all ]

Ron Sigal updated JBREM-788:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29837971.1187404263705.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-793?page=all ]

Ron Sigal updated JBREM-793:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                       2.4.0.Beta1 (Pinto)
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.1.SP1
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7171563.1187404263848.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA
                       2.4.0.Beta1 (Pinto)
                           (was: 2.2.1.SP1)

> Release 2.2.1.SP1
> -----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 17 22:31:04 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22528869.1187404264027.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-767?page=all ]

Ron Sigal updated JBREM-767:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.1.SP1)

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Fri Aug 17 22:31:04 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17404896.1187404264280.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-775?page=all ]

Ron Sigal updated JBREM-775:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.2.0.SP4
                           (was: 2.2.0.SP4_CP02)

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:03 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-784) Use separate maps
 for control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4725159.1187404263396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-784?page=all ]

Ron Sigal updated JBREM-784:
----------------------------

        Fix Version/s: 2.2.2.GA
                       2.4.0.CR1 (Pinto)
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4_CP02)
                           (was: 2.2.1.SP1)
    Affects Version/s: 2.4.0.Beta1 (Pinto)

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:31:04 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-774)
 BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should
 close control socket
In-Reply-To: <6131196.1184213431580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27289085.1187404264157.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-774?page=all ]

Ron Sigal updated JBREM-774:
----------------------------

    Fix Version/s: 2.2.2.GA
                   2.4.0.CR1 (Pinto)
                       (was: 2.4.0.Beta1 (Pinto))
                       (was: 2.2.0.SP4_CP02)
                       (was: 2.2.1.SP1)

> BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should close control socket
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBREM-774
>                 URL: http://jira.jboss.com/jira/browse/JBREM-774
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>
> If cpu overload or network congestion causes a control connection PING to get delayed, the client side org.jboss.remoting.transport.bisocket.Bisocket.BisocketServerInvoker.ControlMonitorTimerTask will tell the server side BisocketServerInvoker.SecondaryServerSocketThread to replace the control socket.  
> If org.jboss.remoting.transport.bisocket.Bisocket.BisocketClientInvoker.replaceControlSocket() does not close the old control socket, and if the client is still alive, the client side BisocketServerInvoker.ControlConnectionThread will be blocked trying to read from an old control connection, which is no longer in use on the server side.
> Also, BisocketClientInvoker.handleDisconnect() should close the control socket.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:37:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.2.GA
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23671420.1187404621104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

    Summary: Release 2.2.2.GA  (was: Release 2.2.1.SP1)

Changed from 2.2.1.SP1 to 2.2.2.GA

> Release 2.2.2.GA
> ----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR1 (Pinto), 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 17 22:41:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-641) re-implement the
 callback polling for http transport to reduce latency
In-Reply-To: <4571412.1164899455840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6799043.1187404861370.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-641?page=all ]

Ron Sigal reopened JBREM-641:
-----------------------------

             
Changes ported for release 2.2.2.GA.

> re-implement the callback polling for http transport to reduce latency
> ----------------------------------------------------------------------
>
>                 Key: JBREM-641
>                 URL: http://jira.jboss.com/jira/browse/JBREM-641
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon), 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:41:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-641) re-implement the
 callback polling for http transport to reduce latency
In-Reply-To: <4571412.1164899455840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3905959.1187404861623.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-641?page=all ]

Ron Sigal updated JBREM-641:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA
                       2.4.0.Beta1 (Pinto)

> re-implement the callback polling for http transport to reduce latency
> ----------------------------------------------------------------------
>
>                 Key: JBREM-641
>                 URL: http://jira.jboss.com/jira/browse/JBREM-641
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon), 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4282123.1187405472554.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-790?page=all ]

Ron Sigal updated JBREM-790:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-784) Use separate maps
 for control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15634231.1187405472663.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-784?page=all ]

Ron Sigal updated JBREM-784:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5918666.1187405472777.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-787?page=all ]

Ron Sigal updated JBREM-787:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:12 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4854528.1187405472905.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-788?page=all ]

Ron Sigal updated JBREM-788:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4470854.1187405473060.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-765?page=all ]

Ron Sigal updated JBREM-765:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8071912.1187405473166.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-782?page=all ]

Ron Sigal updated JBREM-782:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1670455.1187405473289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-785?page=all ]

Ron Sigal updated JBREM-785:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-778)
 BisocketServerInvoker.start() creates a new static Timer each time
In-Reply-To: <3736496.1184968967071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9236954.1187405473412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-778?page=all ]

Ron Sigal updated JBREM-778:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> BisocketServerInvoker.start() creates a new static Timer each time
> ------------------------------------------------------------------
>
>                 Key: JBREM-778
>                 URL: http://jira.jboss.com/jira/browse/JBREM-778
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start() creates a new static Timer each time.  It should only create a new Timer if (1) there is no existing Timer, or (2) the existing Timer has shut down.  See the similar issue JBREM-748.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-761) NPE in
 BisocketServerInvoker$ControlConnectionThread
In-Reply-To: <9608977.1183001997620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32979303.1187405473512.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-761?page=all ]

Ron Sigal updated JBREM-761:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> NPE in BisocketServerInvoker$ControlConnectionThread
> ----------------------------------------------------
>
>                 Key: JBREM-761
>                 URL: http://jira.jboss.com/jira/browse/JBREM-761
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> From Tim Fox:
> Here's one I saw today:
> @main 18:11:54,129 INFO  [FailoverTest] tearing down
> Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException
>        at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669)
> It seems pretty harmless, but nevertheless I thought I'd inform 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 lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9740980.1187405473628.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-783?page=all ]

Ron Sigal updated JBREM-783:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16633688.1187405473780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-767?page=all ]

Ron Sigal updated JBREM-767:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Fri Aug 17 22:51:13 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.2.GA
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26195661.1187405473897.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Release 2.2.2.GA
> ----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2039752.1187405474033.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-766?page=all ]

Ron Sigal updated JBREM-766:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6069949.1187405474154.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-793?page=all ]

Ron Sigal updated JBREM-793:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15186051.1187405474293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-775?page=all ]

Ron Sigal updated JBREM-775:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:51:14 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-774)
 BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should
 close control socket
In-Reply-To: <6131196.1184213431580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19123692.1187405474430.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-774?page=all ]

Ron Sigal updated JBREM-774:
----------------------------

    Fix Version/s: 2.4.0.Beta1 (Pinto)
                       (was: 2.4.0.CR1 (Pinto))

> BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should close control socket
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBREM-774
>                 URL: http://jira.jboss.com/jira/browse/JBREM-774
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If cpu overload or network congestion causes a control connection PING to get delayed, the client side org.jboss.remoting.transport.bisocket.Bisocket.BisocketServerInvoker.ControlMonitorTimerTask will tell the server side BisocketServerInvoker.SecondaryServerSocketThread to replace the control socket.  
> If org.jboss.remoting.transport.bisocket.Bisocket.BisocketClientInvoker.replaceControlSocket() does not close the old control socket, and if the client is still alive, the client side BisocketServerInvoker.ControlConnectionThread will be blocked trying to read from an old control connection, which is no longer in use on the server side.
> Also, BisocketClientInvoker.handleDisconnect() should close the control socket.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:55:20 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:55:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-756) CallbackPoller
 should shut down if too many errors occur.
In-Reply-To: <21704098.1182228191615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7118405.1187405720315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-756?page=all ]

Ron Sigal reopened JBREM-756:
-----------------------------

             
Changes applied to Remoting 2.2.2.GA.

> CallbackPoller should shut down if too many errors occur.
> ---------------------------------------------------------
>
>                 Key: JBREM-756
>                 URL: http://jira.jboss.com/jira/browse/JBREM-756
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.callback.CallbackPoller will keep running even if the connection is broken or server crashes.  It should be possible to specify a maximum number of errors, after which CallbackPoller will quit polling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:55:20 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:55:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-756) CallbackPoller
 should shut down if too many errors occur.
In-Reply-To: <21704098.1182228191615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24221834.1187405720428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-756?page=all ]

Ron Sigal updated JBREM-756:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> CallbackPoller should shut down if too many errors occur.
> ---------------------------------------------------------
>
>                 Key: JBREM-756
>                 URL: http://jira.jboss.com/jira/browse/JBREM-756
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.callback.CallbackPoller will keep running even if the connection is broken or server crashes.  It should be possible to specify a maximum number of errors, after which CallbackPoller will quit polling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:57:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-743) For polling callback
 handler, 
 org.jboss.remoting.Client.addListener() should create only one
 CallbackPoller per InvokerCallbackHandler
In-Reply-To: <28950543.1178341672458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3389313.1187405821238.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-743?page=all ]

Ron Sigal updated JBREM-743:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

Changes ported for Remoting 2.2.2.GA.

> For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-743
>                 URL: http://jira.jboss.com/jira/browse/JBREM-743
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. 
> The semantics, according to Chapter 5 of the Remoting guide, should be
> If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect.
> So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:57:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-755) Make
 ConnectorValidator parameters configurable
In-Reply-To: <9961988.1181953572529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23265073.1187405821413.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-755?page=all ]

Ron Sigal reopened JBREM-755:
-----------------------------

             
Changes ported for Remoting 2.2.2.GA.

> Make ConnectorValidator parameters configurable
> -----------------------------------------------
>
>                 Key: JBREM-755
>                 URL: http://jira.jboss.com/jira/browse/JBREM-755
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Currently org.jboss.remoting.ConnectionValidator hard codes the timeout value (1000 ms) and the number of attempts (1) to get a socket (socket transport family only).  It would be useful to be able to configure these parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:57:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-755) Make
 ConnectorValidator parameters configurable
In-Reply-To: <9961988.1181953572529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9854443.1187405821577.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-755?page=all ]

Ron Sigal updated JBREM-755:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> Make ConnectorValidator parameters configurable
> -----------------------------------------------
>
>                 Key: JBREM-755
>                 URL: http://jira.jboss.com/jira/browse/JBREM-755
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Currently org.jboss.remoting.ConnectionValidator hard codes the timeout value (1000 ms) and the number of attempts (1) to get a socket (socket transport family only).  It would be useful to be able to configure these parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 22:59:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 22:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22605568.1187405941052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-757?page=all ]

Ron Sigal updated JBREM-757:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

Changes ported for Remoting 2.2.2.GA.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 23:01:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-754) Reset timeout on
 each use of HttpURLConnection
In-Reply-To: <3212428.1181272151600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3410829.1187406061267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-754?page=all ]

Ron Sigal reopened JBREM-754:
-----------------------------

             
Changes ported for Remoting 2.2.2.GA.

> Reset timeout on each use of HttpURLConnection
> ----------------------------------------------
>
>                 Key: JBREM-754
>                 URL: http://jira.jboss.com/jira/browse/JBREM-754
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Even though each call to org.jboss.remoting.transport.http.HTTPClientInvoker.invoke() creates a new HttpURLConnection, it seems that the HttpURLConnection implementation caches underlying connections.  When an org.jboss.remoting.ConnectionValidator is running, it connects to the same server as ordinary HTTPClientInvokers used by the application, but it sets a timeout of 1000.  If no timeout value is configured for application connections, then HTTPClientInvoker does not set a timeout on the HttpURLConnection, and a connection with a timeout of 1000 might get reused.
> If no timeout is configured, HTTPClientInvoker should explicitly set the HttpURLConnection connect and read timeouts to 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 lists.jboss.org  Fri Aug 17 23:01:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-754) Reset timeout on
 each use of HttpURLConnection
In-Reply-To: <3212428.1181272151600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13648507.1187406061419.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-754?page=all ]

Ron Sigal updated JBREM-754:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> Reset timeout on each use of HttpURLConnection
> ----------------------------------------------
>
>                 Key: JBREM-754
>                 URL: http://jira.jboss.com/jira/browse/JBREM-754
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Even though each call to org.jboss.remoting.transport.http.HTTPClientInvoker.invoke() creates a new HttpURLConnection, it seems that the HttpURLConnection implementation caches underlying connections.  When an org.jboss.remoting.ConnectionValidator is running, it connects to the same server as ordinary HTTPClientInvokers used by the application, but it sets a timeout of 1000.  If no timeout value is configured for application connections, then HTTPClientInvoker does not set a timeout on the HttpURLConnection, and a connection with a timeout of 1000 might get reused.
> If no timeout is configured, HTTPClientInvoker should explicitly set the HttpURLConnection connect and read timeouts to 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 lists.jboss.org  Fri Aug 17 23:01:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21130247.1187406061556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-771?page=all ]

Ron Sigal updated JBREM-771:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 17 23:32:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-747)
 org.jboss.remoting.transport.Connector should unregister server invoker
 from MBeanServer
In-Reply-To: <8850851.1179472312226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6620747.1187407921103.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-747?page=all ]

Ron Sigal reopened JBREM-747:
-----------------------------

             
Changing fix version from 2.2.1.SP1 to 2.2.2.GA.

> org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-747
>                 URL: http://jira.jboss.com/jira/browse/JBREM-747
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one).  
> The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception 
> javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
>         at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799)
> The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered.  The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker.   As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory 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 lists.jboss.org  Fri Aug 17 23:32:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 17 Aug 2007 23:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-747)
 org.jboss.remoting.transport.Connector should unregister server invoker
 from MBeanServer
In-Reply-To: <8850851.1179472312226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22702926.1187407921216.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-747?page=all ]

Ron Sigal updated JBREM-747:
----------------------------

    Fix Version/s: 2.2.2.GA
                       (was: 2.2.1.SP1)

> org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-747
>                 URL: http://jira.jboss.com/jira/browse/JBREM-747
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one).  
> The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception 
> javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
>         at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799)
> The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered.  The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker.   As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory 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 lists.jboss.org  Sat Aug 18 03:37:11 2007
From: jira-events at lists.jboss.org (Gernot Starke (JIRA))
Date: Sat, 18 Aug 2007 03:37:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1099) Split
 documentation in "reference manual" and "user guide"
Message-ID: <13593324.1187422631455.JavaMail.jira@cloud.prod.atl2.jboss.com>

Split documentation in "reference manual" and "user guide"
----------------------------------------------------------

                 Key: JBRULES-1099
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1099
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation
         Environment: all
            Reporter: Gernot Starke
         Assigned To: Mark Proctor
            Priority: Minor


imho documentation for a product like JBoss Drools should consist of several DISTINCT parts,
at least reference manual and user guide.

That'd make it two different manuals - but especially the language documentation should get
a more promininent location... (reference manual)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 04:20:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sat, 18 Aug 2007 04:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-453)
 maven-jbossaop-plugin requires
 artifact maven-jbossaop-plugin on compile classpath
In-Reply-To: <31000254.1186523875263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25962980.1187425201281.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-453?page=comments#action_12372845 ] 
            
Anders Andersen commented on JBAOP-453:
---------------------------------------

Okay I suddenly see what you mean.
So when the AOPC process needs more artifacts I should add them to the plugin !!!!

I think this is because I understand too little of AOP
So what you mean is that classes needed by AOPC (from my dependent artifacts) might only be needed at AOP compile time, and NOT at runtime.

I would need some testing (of the portal application) to getting this right or wrong.

I still think the project compile classpath should be added to the "AOPC -cp" just in case a class should be used both places. This is (as I see it) a consequence of adding the project.getBuild().getOutputDirectory().

Consider I re-factored my artifact into several artifacts, I should still be able to build it. And in this case some of the refactored classes will come from a project dependency.

> maven-jbossaop-plugin requires artifact maven-jbossaop-plugin on compile classpath
> ----------------------------------------------------------------------------------
>
>                 Key: JBAOP-453
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-453
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: maven 2
>            Reporter: Anders Andersen
>         Assigned To: Stale Pedersen
>
> In order to use the plugin I have to add the following dependencies to the client artifact dependency list.
>     <dependency>
>       <groupId>org.jboss.maven.plugins</groupId>
>       <artifactId>maven-jbossaop-plugin</artifactId>
>       <version>1.0-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-aop</artifactId>
>       <version>2.0.0.alpha2</version>
>     </dependency>
>     <dependency>
>       <groupId>jboss</groupId>
>       <artifactId>jboss-common</artifactId>
>       <version>4.0.2</version>
>     </dependency>
>     <dependency>
>       <groupId>concurrent</groupId>
>       <artifactId>concurrent</artifactId>
>       <version>1.3.4</version>
>     </dependency>
> This is relative wrong, because all maven internal artifacts ends up being nested dependent om the runtime artifact.
> See lists below.
> I think the statement
>       cl.addArguments(new String[] { "-cp", createClassPathList(project.getArtifacts())});
> is wrong.
> I tried to include only project.getPluginArtifacts(), but it gave me a NPE
> So I am not 100% sure what the code solution should be
> but it is not good to having maven artifacts in the resulting dependency list of the client-artifact
> list: (resulting depenency list)
> The ** marked should not be there
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact/2.0.2/maven-artifact-2.0.2.jar
> /Users/aka/.m2/repository/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-opends/2.6.1-SNAPSHOT/portal-test-opends-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/isorelax/isorelax/20020414/isorelax-20020414.jar
> /Users/aka/.m2/repository/jgroups/jgroups-all/2.2.7/jgroups-all-2.2.7.jar
> /Users/aka/.m2/repository/jboss/jboss-common/4.0.2/jboss-common-4.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-xml-binding/5.0.0.Alpha/jboss-xml-binding-5.0.0.Alpha.jar
> /Users/aka/.m2/repository/jboss/jboss-cache/1.2.2/jboss-cache-1.2.2.jar
> /Users/aka/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> /Users/aka/.m2/repository/jboss/jboss-j2se/200504122039/jboss-j2se-200504122039.jar
> /Users/aka/.m2/repository/jboss/jbossha/4.0.2/jbossha-4.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-minimal/4.0.2/jboss-minimal-4.0.2.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-common-client/4.0.4.GA/jboss-common-client-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server/2.6.1-SNAPSHOT/portal-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-saaj/4.0.4.GA/jboss-saaj-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-system/4.0.4.GA/jboss-system-4.0.4.GA.jar
> /Users/aka/.m2/repository/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
> /Users/aka/.m2/repository/org/jboss/portal/core/portal-core/2.6.1-SNAPSHOT/portal-core-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/javassist/3.4.ga/javassist-3.4.ga.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test/2.6.1-SNAPSHOT/portal-test-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/format/portal-format/2.6.1-SNAPSHOT/portal-format-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
> /Users/aka/.m2/repository/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
> /Users/aka/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> /Users/aka/.m2/repository/jboss/jboss-system/4.0.2/jboss-system-4.0.2.jar
> /Users/aka/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar
> /Users/aka/.m2/repository/hibernate/hibernate/3.2.0/hibernate-3.2.0.jar
> /Users/aka/.m2/repository/jboss/jboss-j2ee/4.0.4.GA/jboss-j2ee-4.0.4.GA.jar
> /Users/aka/.m2/repository/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/portal/server/portal-server-test-framework/2.6.1-SNAPSHOT/portal-server-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-artifact-manager/2.0.2/maven-artifact-manager-2.0.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-project/2.0.2/maven-project-2.0.2.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-microcontainer/4.0.4.GA/jboss-microcontainer-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common/2.6.1-SNAPSHOT/portal-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/selenium/selenium-java-client-driver/0.0/selenium-java-client-driver-0.0.jar
> /Users/aka/.m2/repository/javax/portlet/portlet-api/1.0/portlet-api-1.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/theme/portal-theme/2.6.1-SNAPSHOT/portal-theme-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.jar
> /Users/aka/.m2/repository/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss/4.0.4.GA/jboss-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
> /Users/aka/.m2/repository/wsdl4j/wsdl4j/1.5.1/wsdl4j-1.5.1.jar
> /Users/aka/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/jboss/jboss-backport-concurrent/2.1.0.GA/jboss-backport-concurrent-2.1.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/server/jbosssx/4.0.4.GA/jbosssx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> /Users/aka/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> /Users/aka/.m2/repository/trove/trove/1.1-beta-5/trove-1.1-beta-5.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/2.0.0.alpha2/jboss-aop-2.0.0.alpha2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-model/2.0.2/maven-model-2.0.2.jar
> /Users/aka/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> /Users/aka/.m2/repository/log4j/log4j/1.2.8/log4j-1.2.8.jar
> /Users/aka/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet/2.6.1-SNAPSHOT/portal-portlet-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/jboss/jboss-aspect-library/1.5/jboss-aspect-library-1.5.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-server/portal-portlet-server/2.6.1-SNAPSHOT/portal-portlet-server-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jmx/4.0.4.GA/jboss-jmx-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-impl/1.1.1/myfaces-impl-1.1.1.jar
> /Users/aka/.m2/repository/org/apache/maven/maven-repository-metadata/2.0.2/maven-repository-metadata-2.0.2.jar
> /Users/aka/.m2/repository/jboss/jboss-aop/jboss-aop/1.5.0.GA/jboss-aop-1.5.0.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/portal-common-junit/2.6.1-SNAPSHOT/portal-common-junit-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> **/Users/aka/.m2/repository/org/apache/maven/maven-profile/2.0.2/maven-profile-2.0.2.jar
> /Users/aka/.m2/repository/org/visigoths/freemaker/freemarker/2.3.9/freemarker-2.3.9.jar
> /Users/aka/.m2/repository/org/jboss/portal/test/portal-test-agent/2.6.1-SNAPSHOT/portal-test-agent-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-dependency/4.0.4.GA/jboss-dependency-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet-federation/portal-portlet-federation/2.6.1-SNAPSHOT/portal-portlet-federation-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/msv/msv/20020414/msv-20020414.jar
> /Users/aka/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
> /Users/aka/.m2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> /Users/aka/.m2/repository/slide/webdavlib/2.0/webdavlib-2.0.jar
> **/Users/aka/.m2/repository/org/jboss/maven/plugins/maven-jbossaop-plugin/1.0-SNAPSHOT/maven-jbossaop-plugin-1.0-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/web/portal-web/2.6.1-SNAPSHOT/portal-web-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/apache/myfaces/myfaces-api/1.1.1/myfaces-api-1.1.1.jar
> /Users/aka/.m2/repository/org/jboss/portal/wsrp/portal-wsrp-gen/2.6.1-SNAPSHOT/portal-wsrp-gen-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/oswego-concurrent/concurrent/1.3.4/concurrent-1.3.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/jems/portal-jems/2.6.1-SNAPSHOT/portal-jems-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/registration/portal-registration/2.6.1-SNAPSHOT/portal-registration-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/server/jboss-jaxrpc/4.0.4.GA/jboss-jaxrpc-4.0.4.GA.jar
> /Users/aka/.m2/repository/org/jboss/portal/security/portal-security/2.6.1-SNAPSHOT/portal-security-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/api/portal-api/2.6.1-SNAPSHOT/portal-api-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/codehaus/cargo/cargo-core-uberjar/0.8/cargo-core-uberjar-0.8.jar
> /Users/aka/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> /Users/aka/.m2/repository/dom4j/dom4j/1.4/dom4j-1.4.jar
> /Users/aka/.m2/repository/org/jboss/portal/identity/portal-identity/2.6.1-SNAPSHOT/portal-identity-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/common/explode-common/2.6.1-SNAPSHOT/explode-common-2.6.1-SNAPSHOT.jar
> /Users/aka/.m2/repository/org/jboss/portal/portlet/portal-portlet-test-framework/2.6.1-SNAPSHOT/portal-portlet-test-framework-2.6.1-SNAPSHOT.jar
> **/Users/aka/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar
> /Users/aka/.m2/repository/jboss/jnpserver/3.2.3/jnpserver-3.2.3.jar
> /Users/aka/.m2/repository/opends/opends/0.0/opends-0.0.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 lists.jboss.org  Sat Aug 18 05:55:01 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Sat, 18 Aug 2007 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1632) Impossible to
 deactivate registration in WSRP producer configuration.
In-Reply-To: <1352609.1187257381672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28927079.1187430901145.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1632?page=all ]

Chris Laprun resolved JBPORTAL-1632.
------------------------------------

    Resolution: Done

> Impossible to deactivate registration in WSRP producer configuration.
> ---------------------------------------------------------------------
>
>                 Key: JBPORTAL-1632
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1632
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Empty producer-configuration is not authorized in the DTD, in particular.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 08:09:01 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Sat, 18 Aug 2007 08:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16179303.1187438941194.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1042?page=all ]

Ronald van Kuijk reopened JBPM-1042:
------------------------------------

             
Hmmm... maybe  a wrong assumption on my side. In one of my local tests where I get this token locked error, it is fixed by the checkins in cvs. I'll reopen and investigate some more

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 08:12:04 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Sat, 18 Aug 2007 08:12:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19284885.1187439124844.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1614?page=all ]

Boleslaw Dawidowicz reopened JBPORTAL-1614:
-------------------------------------------

             
I needed to rolback this commit for now as testsuite was failing and there were deployment issues. Maybe some other stuff conflicted with it

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 10:28:15 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Aug 2007 10:28:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4613) JBossCacheManager
 active session count should include backup sessions
Message-ID: <6215880.1187447295367.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossCacheManager active session count should include backup sessions
---------------------------------------------------------------------

                 Key: JBAS-4613
                 URL: http://jira.jboss.com/jira/browse/JBAS-4613
             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.Beta3


The usage of the max active session configuration in JBossCacheManager currently only applies to sessions that are being used in the local node -- it ignores how many sessions are stored in the distributed cache.  This makes little sense, since the primary purpose of controlling the session count is to control memory resources.  A session in the distributed cache takes memory resources just as much as a locally used one does.

With this change, when the Manager checks whether there are excess sessions, the maxActive property value will be compared against an "active" count derived as follows:

visible sessions = count of locally accessed sessions + count of sessions in the local instance of the distributed cache that have not been locally accessed
active sessions = visible sessions - sessions passivated locally

The value of that calculation is what will be returned by the getActiveSessionCount() method.

If the active session count >= maxActive, the session expiration/passivation method (processExpires()) will be executed before a new session is created.  If after expiration/passivation the active session count still exceeds maxActive, the session creation request will be rejected with an IllegalStateException. (Rejecting the attempt to create excess sessions is not new; all that has changed is the calculation.) 

The same comparison is used within processExpires() to determine whether sessions that have reached their configured passivation-min-idle-time need to be passivated.

Note that the value of "active sessions" will depend on whether the distributed cache is using buddy replication, as that will impact the number of sessions stored in the local instance of the distributed cache:

1) If buddy replication is disabled, a copy of all sessions used on any node in the cluster will be stored in the local instance of the distributed cache.

2) If buddy replication is enabled (the default in 5.x), only sessions hosted by cluster nodes for which the current node is serving as a buddy will be stored in the local instance of the distributed cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 11:06:01 2007
From: jira-events at lists.jboss.org (Anders Andersen (JIRA))
Date: Sat, 18 Aug 2007 11:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1615) Maven2 poms
 initial version ready for portal
In-Reply-To: <4157740.1185486047091.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31041773.1187449561670.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1615?page=all ]

Anders Andersen updated JBPORTAL-1615:
--------------------------------------

    Attachment: _maven-08-18.tar.gz

Updated to todays trunk
fixed:
1)  core-admin test war and sar is build
2)  AOPC plugin seems now to work fully
3)  intelliJ files are removed from "kit" (use mvn idea:idea to establish em)


> Maven2 poms initial version ready for portal
> --------------------------------------------
>
>                 Key: JBPORTAL-1615
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1615
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>         Environment: unix script used (use unix or cygwin)
>            Reporter: Anders Andersen
>         Attachments: _maven-08-05.tar.gz, _maven-08-18.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz, _maven.tar.gz
>
>          Time Spent: 1 day, 5 hours
>  Remaining Estimate: 0 minutes
>
> The _maven directory will contain a complete maven2 build environment for the jboss portal
> prepare:
>           If you are running windows --> install cygwin and run bash from here
>           1) #install maven2 (2.0.6) or later
>           2) #install the jboss-packaging-maven-plugin
>              svn co https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/jboss-packaging-maven-plugin jboss-packaging-maven-plugin
>              mvn -f jboss-packaging-maven-plugin/pom.xml install
>           3) #install the portal
>              svn co http://anonsvn.jboss.org/repos/portal/trunk jboos-portal
>              cd jboss-portal
>              build/build.sh clean most
>           4) unzip the _maven into jboss-portal
>           5) cd _maven
>              cd _deploy
>              # deploy the third party artifacts that I did not find on the internet
>              # edit the script to meet your settings before running
>              ./third-party-deploy.sh
>           6) #prepare the maven source locations
> usage:       #run script
>              ./_build.sh
> post steps:
>           7) #maven build the jboss 2.6 portal
>              mvn clean install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 12:07:16 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Sat, 18 Aug 2007 12:07:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1100) BRMS Bug on view
 source in weblogic
Message-ID: <10407110.1187453236080.JavaMail.jira@cloud.prod.atl2.jboss.com>

BRMS Bug on view source in weblogic
-----------------------------------

                 Key: JBRULES-1100
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1100
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA,  4.0.0.MR3, 4.0.0.MR2
         Environment: OS: Any 
Application Server: Weblogic > 9.2
            Reporter: Fernando Meyer
         Assigned To: Fernando Meyer
             Fix For: 4.0.1


When trying to view source brms is using eclipse instead janino

|####<Aug 18, 2007 1:59:34 AM BRT> <Error> <ServletContext-/drools-jbrms> <localhost.localdomain> <examplesServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1187413174144> <000000> <Exception while dispatching incoming RPC call
org.drools.RuntimeDroolsException: Unable to load dialect ' org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java'
        at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:138)
        at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
        at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
        at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
        at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
        at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
        at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
        at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
        at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
        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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
        at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
java.lang.RuntimeException : The Eclipse JDT Core jar is not in the classpath
        at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.setCompiler(JavaDialectConfiguration.java:98)
        at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.init (JavaDialectConfiguration.java:56)
        at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:134)
        at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
        at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
        at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
        at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
        at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
        at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
        at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
        at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
        at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
        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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
        at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
        at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 12:18:15 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Sat, 18 Aug 2007 12:18:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1100) BRMS Bug on view
 source in weblogic
In-Reply-To: <10407110.1187453236080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22950921.1187453895033.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1100?page=all ]

Fernando Meyer resolved JBRULES-1100.
-------------------------------------

    Resolution: Done

> BRMS Bug on view source in weblogic
> -----------------------------------
>
>                 Key: JBRULES-1100
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1100
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.0.MR2,  4.0.0.MR3,  4.0.0.GA
>         Environment: OS: Any 
> Application Server: Weblogic > 9.2
>            Reporter: Fernando Meyer
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> When trying to view source brms is using eclipse instead janino
> |####<Aug 18, 2007 1:59:34 AM BRT> <Error> <ServletContext-/drools-jbrms> <localhost.localdomain> <examplesServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1187413174144> <000000> <Exception while dispatching incoming RPC call
> org.drools.RuntimeDroolsException: Unable to load dialect ' org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java'
>         at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:138)
>         at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
>         at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
>         at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
>         at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
>         at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
>         at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
>         at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
>         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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
>         at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
> java.lang.RuntimeException : The Eclipse JDT Core jar is not in the classpath
>         at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.setCompiler(JavaDialectConfiguration.java:98)
>         at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.init (JavaDialectConfiguration.java:56)
>         at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:134)
>         at org.drools.compiler.PackageBuilderConfiguration.init (PackageBuilderConfiguration.java:114)
>         at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:87)
>         at org.drools.brms.server.ServiceImplementation.buildAssetSource (ServiceImplementation.java:777)
>         at org.drools.brms.server.ServiceImplementation$$FastClassByCGLIB$$8f2fab45.invoke(<generated>)
>         at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
>         at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke (RollbackInterceptor.java:34)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java :47)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
>         at org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:37)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed (SeamInvocationContext.java:69)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java :154)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
>         at org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$ea689016.buildAssetSource(<generated>) 
>         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.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
>         at org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
>         at javax.servlet.http.HttpServlet.service (HttpServlet.java:763)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 14:13:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 18 Aug 2007 14:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1045) Predicate Null
 Pointer exception when using Java 5 Enum
In-Reply-To: <11289278.1185770821666.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4873229.1187460781251.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1045?page=all ]

Edson Tirelli closed JBRULES-1045.
----------------------------------

    Resolution: Done

Fixed. Parser dos not accept invalid constructs like that anymore. Unit test added.

> Predicate Null Pointer exception when using Java 5 Enum
> -------------------------------------------------------
>
>                 Key: JBRULES-1045
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1045
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, Jboss Rules 4.0.0 GA, Sun Java 1.5.0_11 VM, Eclipse 3.3 with JBOss Rules IDE 4.0 
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Java 5 enums as column constraint do not work as expected.  Cqauses Null pointer exception in mvel.MVELPredicateExpression.evaluate.
> Using modified Eclipse generated  Sample project to demonstrate:
> DroolsTest now has an Enum for it's Message:
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> /**
>  * This is a sample file to launch a rule package from a rule source file.
>  */
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.insert(Message.HELLO);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         // read in the source
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/Sample.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
>     public enum Message {
>         GOODBYE, HELLO;
>     }
> }
> The Sample.drl rule is modified to:
> package com.sample
> import com.sample.DroolsTest.Message;
> rule "Hello World"
>   when
>     m : Message( Message.HELLO )
>   then
>     System.out.println( m );
> end
> Stack trace given is:
> org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 10382a9
> 	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:21)
> Caused by: java.lang.NullPointerException
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:39)
> 	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191)
> 	... 10 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 lists.jboss.org  Sat Aug 18 17:24:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Aug 2007 17:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4548) Testsuite failures
 due to EJBs starting before datasource
In-Reply-To: <21518359.1184384643755.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5466543.1187472241279.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4548?page=comments#action_12372868 ] 
            
Brian Stansberry commented on JBAS-4548:
----------------------------------------

I have added test org.jboss.test.deployers.ear.test.EmbeddedDatasourceUnitTestCase that shows this issue. With that in place I plan to modify the clustering tests mentioned in the above description to work around this issue.

> Testsuite failures due to EJBs starting before datasource
> ---------------------------------------------------------
>
>                 Key: JBAS-4548
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4548
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Deployment services
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Brian Stansberry
>         Assigned To: Dimitris Andreadis
>
> A number of unit tests are failing due to EJB2 deployment failures.  The tests deploy an ear; contents of the ear are an ejb2 jar and a -ds.xml file.  The ejb jar is deploying before the datasource, and thus ejb deployment fails when the datasource cannot be found in JNDI.
> See forum thread for detailed discussion.
> The testsuite failures due to this that I'm aware of are:
> org.jboss.test.testbeancluster.test.CacheInvalidationUnitTestCase
> org.jboss.test.testbeancluster.test.RetryInterceptorUnitTestCase
> org.jboss.test.testbeancluster.test.SingleRetryInterceptorUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 18 23:28:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Aug 2007 23:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4614)
 UnifiedInvokerHAProxy does not implement InvokerProxyHA
Message-ID: <9418263.1187494081162.JavaMail.jira@cloud.prod.atl2.jboss.com>

UnifiedInvokerHAProxy does not implement InvokerProxyHA
-------------------------------------------------------

                 Key: JBAS-4614
                 URL: http://jira.jboss.com/jira/browse/JBAS-4614
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


UnifiedInvokerHAProxy does not implement InvokerProxyHA.  Because of this, ProxyFactoryHA will not update a unified invoker proxy's target list when it gets a notification of a cluster topology change.  Effect is a client downloading the proxy will always get the set of targets available when the proxy was created.

Usually the downloaded proxy will also have at least one valid target (the one for the node that created the proxy.) As soon as the client makes an invocation, the server will detect they have a stale view and piggyback the current targets with the response. So, this bug is not very likely to cause an invocation failure, but it does reduce the robustness of the proxy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 01:32:01 2007
From: jira-events at lists.jboss.org (Yuri de Wit (JIRA))
Date: Sun, 19 Aug 2007 01:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
Message-ID: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>

MVEL direct property accessors being converted to a ReturnValueConstraint
-------------------------------------------------------------------------

                 Key: JBRULES-1101
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Yuri de Wit
         Assigned To: Mark Proctor


After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.

So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 01:36:01 2007
From: jira-events at lists.jboss.org (Yuri de Wit (JIRA))
Date: Sun, 19 Aug 2007 01:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1102) Bug in
 DefaultBetaConstraint class indexing to never turn on
Message-ID: <22237245.1187501761200.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bug in DefaultBetaConstraint class indexing to never turn on
------------------------------------------------------------

                 Key: JBRULES-1102
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1102
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Yuri de Wit
         Assigned To: Mark Proctor


Look at line 75 of DefaultBetaConstraint: notice the (depth <= this.indexed). This will always evaluate to false. It should be this.indexed < depth

This bug and the one reported here (http://jira.jboss.com/jira/browse/JBRULES-1101) make sure that indexing is not used 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 lists.jboss.org  Sun Aug 19 04:13:01 2007
From: jira-events at lists.jboss.org (Wise Guy (JIRA))
Date: Sun, 19 Aug 2007 04:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-70)
 Interceptor.onLoad not called from EJB3 event listeners
Message-ID: <26959250.1187511181135.JavaMail.jira@cloud.prod.atl2.jboss.com>

Interceptor.onLoad not called from EJB3 event listeners
-------------------------------------------------------

                 Key: HIBERNATE-70
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-70
             Project: Hibernate
          Issue Type: Bug
         Environment: JBoss 4.2.1.GA, Hibernate 3.2.1 SP1, Seam 1.2.1.GA
            Reporter: Wise Guy
         Assigned To: Steve Ebersole
            Priority: Minor


I have a Seam 1.2.1.GA application. I installed an implementation of the interface org.hibernate.Interceptor and declared it in the persistence.xml as hibernate.ejb.interceptor.

The interceptor works (ex.: onSave(), onFlushDirty()) except that onLoad() doesn't get called. 

I guess that there is a problem with the DefaultPreLoadEventListener who should call my interceptor. He is defined in org.hibernate.event.EventListeners as a default listener to the event "pre-load". I also found that the DefaultLoadEventListener.onLoad() gets called but DefaultPreLoadEventListener.onPreLoad() not. Does that have something to do with EJB3? I have found that there is an EJB3PostLoadEventListener that is used when run under JPA and the default listeners are overridden.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 11:17:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Aug 2007 11:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-642) Extract solver
	configuration
In-Reply-To: <33397392.1170512250040.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18199450.1187536621231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-642?page=all ]

Geoffrey De Smet resolved JBRULES-642.
--------------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

fixed

> Extract solver configuration
> ----------------------------
>
>                 Key: JBRULES-642
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-642
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Solver
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 4.0.1
>
>
> Preferable into an xml file.
> Should help to make the integration tests easier 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 lists.jboss.org  Sun Aug 19 11:19:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Aug 2007 11:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-678) Remove spring
	dependency
In-Reply-To: <4908345.1171728569969.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30881876.1187536741065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-678?page=all ]

Geoffrey De Smet resolved JBRULES-678.
--------------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

fixed

> Remove spring dependency
> ------------------------
>
>                 Key: JBRULES-678
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-678
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Solver
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Once the configuration xml is extracted this should be a peice of cake

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 11:21:01 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Aug 2007 11:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1103) Tabu asperation
 based on stepscore
Message-ID: <19288912.1187536861044.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tabu asperation based on stepscore
----------------------------------

                 Key: JBRULES-1103
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1103
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Solver
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
             Fix For: FUTURE


Move tabu and property tabu could use "aspiration"
Basically even if it's tabu, a move is accepted if the stepscore improves.

For solution tabu this is pointless.
Aspiration should occur on stepScore and NOT on decisionScore

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 15:45:01 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Sun, 19 Aug 2007 15:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1606) Portlet and
 service to see current users online
In-Reply-To: <7812771.1185034607642.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <827527.1187552701857.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1606?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1606.
-------------------------------------------

    Resolution: Done

commited. I also added support for cluster environment using ha jmx notifications

> Portlet and service to see current users online
> -----------------------------------------------
>
>                 Key: JBPORTAL-1606
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1606
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal Samples
>    Affects Versions: 2.6 Final
>         Environment: developed with Eclipse 3.2.2 and jboss portal from http://anonsvn.jboss.org/repos/portal/tags/JBoss_Portal_2_6_0
>            Reporter: Luca Stancapiano
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 Final
>
>         Attachments: UsersOnline.zip, UsersOnline.zip, UsersOnline.zip
>
>
> I developed together with Bolek a portlet and service to see current users online.
> UI part is into portal-samples project. Modified and added files are:
> // descriptors for portlet......I add portal-lib.tld to get support for i18n and Context to send info from portlet to jsp
> core-samples/src/resources/portal-users-samples-war/WEB-INF/portlet.xml
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jboss-portlet.xml
> core-samples/src/resources/portal-users-samples-war/WEB-INF/portal-lib.tld
> core-samples/src/resources/portal-users-samples-war/WEB-INF/portlet-instances.xml
> // I create three jsp....one when no user is online, one when there is a only user online and one for all other users online
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jsp/users/oneUser.jsp
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jsp/users/users.jsp
> core-samples/src/resources/portal-users-samples-war/WEB-INF/jsp/users/noUser.jsp
> // I add support for i18n with english and italian language
> core-samples/src/resources/portal-users-samples-war/WEB-INF/classes/Resource.properties
> core-samples/src/resources/portal-users-samples-war/WEB-INF/classes/Resource_it.properties
> // this is a simple portlet that call a UserActivityService that schedule activities of users. This portlet print current users online and number of current users online
> core-samples/src/main/org/jboss/portal/core/samples/users/CurrentUsersPortlet.java
> // I updated build.xml to build portal-users-samples.war package to deploy it into application server
> core-samples/build.xml
> part about service and interceptor is into core:
> // we add UsersActivityStatsService service and UserStats interceptor. The interceptor is added into InterceptorStackFactory,type=Server of jboss portal to catch all activities of users.
> // rows updated are: 
> core/src/resources/portal-core-sar/META-INF/jboss-service.xml
> // classes for  UsersActivityStatsService service. There are an interface of service, an implementation and a class that represents an user activity registered into the service
> core/src/main/org/jboss/portal/core/identity/UsersActivityStatsServiceImpl.java
> core/src/main/org/jboss/portal/core/identity/UsersActivityStatsService.java
> core/src/main/org/jboss/portal/core/identity/UserActivity.java
> // this is UserStats interceptor
> core/src/main/org/jboss/portal/core/aspects/server/UserStatsInterceptor.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 lists.jboss.org  Sun Aug 19 18:44:01 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Sun, 19 Aug 2007 18:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1077) Decision tables to
 have ruleflow-group attribute column
In-Reply-To: <30015767.1186969861144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28283074.1187563441196.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1077?page=all ]

Michael Neale closed JBRULES-1077.
----------------------------------


Closing issue as mark likes things to be closed when done (we aren't really sure what resolved means - if something regresses we can re-open a closed one anyway - I think resolved is when there is a traditional testing/QA department and they have to sign off that it was indeed done).

> Decision tables to have ruleflow-group attribute column
> -------------------------------------------------------
>
>                 Key: JBRULES-1077
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1077
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Fernando Meyer
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> In decision tables, we can set no-loop attributes (amongst others) by haveing a special keyword in a column (chekc the code for how this is done). Would like to add ruleflow-group to this 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 lists.jboss.org  Sun Aug 19 22:18:01 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 19 Aug 2007 22:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1104) Inserted Objects
 are lost if no matching ObjectTypeNodes
Message-ID: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>

Inserted Objects are lost if no matching ObjectTypeNodes
--------------------------------------------------------

                 Key: JBRULES-1104
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Edson Tirelli
             Fix For: 4.0.1


We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 22:42:05 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 19 Aug 2007 22:42:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4615) NamingContext caches
 stale Naming stub
Message-ID: <17323116.1187577725144.JavaMail.jira@cloud.prod.atl2.jboss.com>

NamingContext caches stale Naming stub
--------------------------------------

                 Key: JBAS-4615
                 URL: http://jira.jboss.com/jira/browse/JBAS-4615
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3


As an important performance optimization, org.jnp.interfaces.NamingContext statically caches a WeakReference to the "proxy" to the server-side Naming service.  In most cases this is either an RMI stub (non-HA naming service) or a proxy based on an HARMIClient (for HA-JNDI).  Either way, the cached object uses RMI to communicate with the server.

This object becomes invalid if the server (non-HA case) or cluster (HA case) it was associated with is restarted.  The object in the restarted server-side RMI runtime will no longer match the client-side RMI stub, and an invocation over the stub will result in a java.rmi.NoSuchObjectException on the client.  NamingContext's caching of the RMI greatly increases the odds of this occuring.  If this occurs, the cache will be flushed and the next call will acquire a fresh stub from the server, but the client will get an exception on the first call.

Proposed solution is discussed on forum thread.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 19 23:12:01 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 19 Aug 2007 23:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4616) NamingContext
 lookupLink() does not acquire stub to server Naming service
Message-ID: <10742725.1187579521074.JavaMail.jira@cloud.prod.atl2.jboss.com>

NamingContext lookupLink() does not acquire stub to server Naming service
-------------------------------------------------------------------------

                 Key: JBAS-4616
                 URL: http://jira.jboss.com/jira/browse/JBAS-4616
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3


org.jnp.interfaces.NamingContext.lookupLink(Name) does not invoke the checkRef() method before invoking on the stub to the server-side Naming object.  The checkRef() method is what actually contacts the JNDI server to download the stub.. Result of this is an NPE will be thrown if an earlier call hasn't downloaded the stub before lookupLink() 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 lists.jboss.org  Mon Aug 20 00:46:17 2007
From: jira-events at lists.jboss.org (Michael Max (JIRA))
Date: Mon, 20 Aug 2007 00:46:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1105) web.xml does not
 conform web-app_2_3.dtd
Message-ID: <3916092.1187585177133.JavaMail.jira@cloud.prod.atl2.jboss.com>

web.xml does not conform web-app_2_3.dtd
----------------------------------------

                 Key: JBRULES-1105
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1105
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Glassfish
            Reporter: Michael Max
         Assigned To: Mark Proctor
             Fix For:  4.0.0.GA


web.xml does not comply with a http://java.sun.com/dtd/web-app_2_3.dtd specification. Because of that drools-jbrms.war cannot be deployed to the servers with a strict validation as Glassfish, just to JBoss AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 01:28:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 20 Aug 2007 01:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-794)
 LeasePinger.addClient() should
 not create a new LeaseTimerTask if none currently exists
Message-ID: <18755133.1187587681051.JavaMail.jira@cloud.prod.atl2.jboss.com>

LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists
---------------------------------------------------------------------------------------

                 Key: JBREM-794
                 URL: http://jira.jboss.com/jira/browse/JBREM-794
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)


When org.jboss.remoting.LeasePinger.addClient() adds a new org.jboss.remoting.Client with a shorter ping period, it restarts the LeaseTimerTask.  However, org.jboss.remoting.MicroRemoteClientInvoker.establishLease() calls LeasePinger.addClient() before it calls LeasePinger.startPing().  LeasePinger incorrectly creates a LeaseTimerTask in addClient() and then creates a second one in startPing().

LeasePinger.addClient() should be changed so that it starts a new LeaseTimerTask only if one already 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 lists.jboss.org  Mon Aug 20 01:37:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 01:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1097) Manual
 html_single does not have TOC entry for Chapter 9 BRMS
In-Reply-To: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30624662.1187588221225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1097?page=all ]

Fernando Meyer reassigned JBRULES-1097:
---------------------------------------

    Assignee: Fernando Meyer  (was: Michael Neale)

> Manual html_single does not have TOC entry for Chapter 9 BRMS
> -------------------------------------------------------------
>
>                 Key: JBRULES-1097
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Jeff DeLong
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:05:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 20 Aug 2007 02:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20069174.1187589901060.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-782?page=comments#action_12372888 ] 
            
Ron Sigal commented on JBREM-782:
---------------------------------

Actually, the first attempt introduced a race condition.  The solution is to move org.jboss.remoting.Client.connect() out of ServerInvokerCallbackHandler() into a new method, ServerInvokerCallbackHandler.connect().

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA, 2.2.0.SP4, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:12:01 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 20 Aug 2007 02:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8059683.1187590321526.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-749?page=all ]

Ron Sigal updated JBREM-749:
----------------------------

        Fix Version/s: 2.2.2.GA
    Affects Version/s: 2.2.0.SP4
                       2.2.1.GA

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:19:01 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 02:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1097) Manual html_single
 does not have TOC entry for Chapter 9 BRMS
In-Reply-To: <9971509.1187309821192.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29027079.1187590741120.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1097?page=all ]

Fernando Meyer closed JBRULES-1097.
-----------------------------------

    Resolution: Done

missing chapter tag corrected

> Manual html_single does not have TOC entry for Chapter 9 BRMS
> -------------------------------------------------------------
>
>                 Key: JBRULES-1097
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1097
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Jeff DeLong
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Manual html_single does not have TOC entry for Chapter 9 BRMS. It does have a TOC entry for Chapter 8 Example, but there is not information under the Chapter Heading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:36:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3273080.1187591761138.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-510?page=comments#action_12372894 ] 
            
Bela Ban commented on JGRP-510:
-------------------------------

Added exponential_backoff, use_stats_for_retransmission, as explained in [1]

[1] http://www.jgroups.org/javagroupsnew/docs/manual/html/protlist.html#d0e3194

> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:36:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32971463.1187591761289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-510?page=all ]

Bela Ban resolved JGRP-510.
---------------------------

    Resolution: Done

> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:38:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-510) NAKACK: adjust
 retransmission times based on statistics
In-Reply-To: <14325994.1179100562388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1068924.1187591881056.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-510?page=comments#action_12372895 ] 
            
Bela Ban commented on JGRP-510:
-------------------------------

Retransmission stats over time can be seen by enabling enable_xmit_time_stats. When the program is terminated, the stats will be dumped to a file suffixed by the address of the member. Note that, since all stats are kept in memory, memory will accumulate over time, so this property is only for diagnosis !

> NAKACK: adjust retransmission times based on statistics
> -------------------------------------------------------
>
>                 Key: JGRP-510
>                 URL: http://jira.jboss.com/jira/browse/JGRP-510
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender.
> The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. 
> If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. For each successfully retransmitted message, we reduce the timeout linearly. This is similar to slow start in TCP.
> When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission.
> OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests.
> RESULT: message retransmission is more dynamic:
> - Retransmit timeout is *per sender*
> - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates
> - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 02:40:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 02:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-180) Harden stack to
 prevent loss of intra-stack events
Message-ID: <7523123.1187592001317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-180?page=all ]

Bela Ban updated JGRP-180:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Haven't run into this scenario yet, so I move it to 2.x

> Harden stack to prevent loss of intra-stack events
> --------------------------------------------------
>
>                 Key: JGRP-180
>                 URL: http://jira.jboss.com/jira/browse/JGRP-180
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9, 2.2.9.1, 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> When an *intra-stack* event is lost, this can be serious (*inter-stack* message are simply retransmitted, so that is not critical).
> Losses are mainly caused by runtime exceptions, e.g. OutOfMemory exception (OOM), or resource problems, and to a lesser extent by program bugs.
> For example, when a user sends a message using Channel.send(), and there is an exception, then the user will simply send the message again, possibly after fixing the cause of the exception.
> However, for events such as VIEW_CHANGE that are multicast by the GMS protocol, a loss can be serious: in this case, the view would never be received !
> The same applies to the up direction: when NAKACK has successfully delivered a message, if that message is lost travelling between NAKACK and the Channel, then is serious (essentially loss of that message).
> So while these error situations don't occur very often, if they do occur, they have serious consequences.
> SOLUTION:
> - Do nothing for user messages: Channel.send() throws an exception, user has to resend message. Note that in http://jira.jboss.com/jira/browse/JGRP-179, we made retransmission handling atomic, e.g. if there is an exception, there will *not* be a gap in the seqnos for NAKACK and UNICAST
> - Provide either a pass{Up/Down}Reliably() method or an Event with a RELIABLE field, such that this event needs to be acked. The sender (e.g. GMS on a VIEW_CHANGE) sends down the message and waits until it gets an ACK, which could be sent by the NAKACK or UNICAST protocols, or as last resort by the transport (TP). If the ACK is not received within M ms, the event is resent. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:34:17 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 03:34:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-574) UnicastChannelTest
	doesn't work
In-Reply-To: <8228116.1187104561702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10628099.1187595257008.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-574?page=comments#action_12372897 ] 
            
Bela Ban commented on JGRP-574:
-------------------------------

Fixed. However, currently flow control (FC) is not enabled for unicast connnections, we need to enable that later on (if a lot of people ever use unicast connections)

> UnicastChannelTest doesn't work
> -------------------------------
>
>                 Key: JGRP-574
>                 URL: http://jira.jboss.com/jira/browse/JGRP-574
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Messages are not received 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:34:17 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 03:34:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-574) UnicastChannelTest
	doesn't work
In-Reply-To: <8228116.1187104561702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13359930.1187595257156.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-574?page=all ]

Bela Ban resolved JGRP-574.
---------------------------

    Resolution: Done

> UnicastChannelTest doesn't work
> -------------------------------
>
>                 Key: JGRP-574
>                 URL: http://jira.jboss.com/jira/browse/JGRP-574
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Messages are not received 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:38:01 2007
From: jira-events at lists.jboss.org (Carsten Christensen (JIRA))
Date: Mon, 20 Aug 2007 03:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-425) Exception when
 an entity persisted and removed in the same JTA
Message-ID: <26306137.1187595481733.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-425?page=comments#action_12372898 ] 
            
Carsten Christensen commented on EJBTHREE-425:
----------------------------------------------

Hi, i still see this error, and none of the workarounds seems to work.

My Entity is in a inherritance heraki, where i have 

@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public abstract class Element implements Serializable
{	
	
	@Id
	@GeneratedValue
	@Column(name = "elementId", unique = true, nullable = false)
	@NotNull
	private int elementId;
	
	@ManyToOne(optional=true)
	@JoinColumn(name="pageId", nullable=false)
	private Page page;
.....
}

@Entity
public class ExtElement extends Element {

	//, cascade=CascadeType.ALL
	@OneToMany(fetch = FetchType.EAGER, mappedBy="explainText")
	@MapKey(name="languageId")
	private Map<Integer,ExtElementLanguage> extElementLanguages;
....
}


when i do 

em.remove(em.merge(element));

i get the error:

09:18:56,332 FATAL [application] javax.ejb.EJBTransactionRolledbackException: deleted entity passed to persist: [my.package.Element#<null>]
javax.faces.el.EvaluationException: javax.ejb.EJBTransactionRolledbackException: deleted entity passed to persist: [my.package.Element#<null>]
	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:91)
......

This is badly influencing customers, do you have any solution?

have tried to split the line to em.merge(element); em.remove.element()
toss in flush and clear() etc



> Exception when an entity persisted and removed in the same JTA
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-425
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-425
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
>            Reporter: Jens Elkner
>
> JBoss/Hibernate throws an exception, if an entity is persisted and later removed in the same JTA, even when em.flush() has been called before removal.
> org.hibernate.ObjectDeletedException: deleted entity passed to persist ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 03:50:07 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 03:50:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-528) NAKACK: spurious
 retransmission requests
In-Reply-To: <29689518.1181634251598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13533095.1187596207325.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-528?page=all ]

Bela Ban resolved JGRP-528.
---------------------------

    Resolution: Cannot Reproduce Bug

In 2.6, I cannot reproduce this

> NAKACK: spurious retransmission requests 
> -----------------------------------------
>
>                 Key: JGRP-528
>                 URL: http://jira.jboss.com/jira/browse/JGRP-528
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> Every now and then, spurious retransmission requests are received:
> NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)]
> It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message.
> This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads).
> Note that this issue DOES NOT LEAD TO INCORRECT BEHAVIOR !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 07:18:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 07:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-462) NAKACK: remove
 bundling for retransmitted messages
In-Reply-To: <11395734.1175874298473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12002758.1187608681209.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-462?page=all ]

Bela Ban resolved JGRP-462.
---------------------------

    Resolution: Done

Simplification of code, performance is the same

> NAKACK: remove bundling for retransmitted messages
> --------------------------------------------------
>
>                 Key: JGRP-462
>                 URL: http://jira.jboss.com/jira/browse/JGRP-462
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> In NAKACK, all retransmitted messages are sent in batches (governed by max_xmit_size). This is redundant, as TP also provides bundling. A quick change of code showed that individual retransmissions is as fast as batched retransmission. This functionality can therefore 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 lists.jboss.org  Mon Aug 20 08:22:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 20 Aug 2007 08:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
In-Reply-To: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3989838.1187612521202.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1031?page=all ]

Carlo de Wolf reassigned EJBTHREE-1031:
---------------------------------------

    Assignee: Carlo de Wolf  (was: William DeCoste)

> runaway SLSB instance creation with ThreadLocalPool
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1031
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Carlo de Wolf
>
> Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:38:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 08:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1150394.1187613481926.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1101?page=all ]

Edson Tirelli reassigned JBRULES-1101:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:40:02 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 08:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10105402.1187613602240.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1101?page=comments#action_12372914 ] 
            
Edson Tirelli commented on JBRULES-1101:
----------------------------------------

Yuri,

Can you please show me one of your rules that were having such problem?

Thank you,
Edson

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:46:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 08:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1092) Invalid Java
 code generated from 'accumulate' function with nested classes
In-Reply-To: <22762348.1187266681169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13903360.1187613961815.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1092?page=all ]

Edson Tirelli reassigned JBRULES-1092:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Invalid Java code generated from 'accumulate' function with nested classes
> --------------------------------------------------------------------------
>
>                 Key: JBRULES-1092
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1092
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>
> Steps to reproduce:
> - Create a sample new project with the Eclipse plugin
> - Add following rule to the .drl file
> - Execute DroolsTest
> rule "AccumulateTest"
> 	no-loop true
> 	when
> 		$d: Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( total += $status ),
>                               result( total )
>                          )
> 	then
> 		System.out.println( "ok" ); 
> 		
> end
> Exception is:
> org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=AccumulateTest, agendaGroup=MAIN, salience=0, no-loop=true]
> 	com/sample/Rule_AccumulateTest_0.java (27:834) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (27:869) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : Syntax error, insert ";" to complete Statement
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : $status cannot be resolved
> 	com/sample/Rule_AccumulateTest_0.java (39:1483) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (39:1518) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:64)
> 	at com.sample.DroolsTest.main(DroolsTest.java:21)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:52:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 08:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-487) Rewrite Retransmitter
In-Reply-To: <24146495.1177407030465.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19360260.1187614321743.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-487?page=all ]

Bela Ban resolved JGRP-487.
---------------------------

    Resolution: Done

Much simpler (= maintainable) code now and same or even slightly better performance

> Rewrite Retransmitter
> ---------------------
>
>                 Key: JGRP-487
>                 URL: http://jira.jboss.com/jira/browse/JGRP-487
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: Retransmitter.java
>
>
> The old Retransmitter is (a) too complex and (b) uses a linear list of Entries as retransmission list, which has a cost proportional to the number of messages in the retransmit buffer.
> We should switch to using simple scheduled futures with the TimeScheduler for retransmissions and cancel the futures when a message has been acked.
> The new Retransmitter.java is 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 lists.jboss.org  Mon Aug 20 08:52:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 20 Aug 2007 08:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
In-Reply-To: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26024741.1187614322176.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1031?page=all ]

Carlo de Wolf updated EJBTHREE-1031:
------------------------------------

    Fix Version/s: AS 4.2.2.GA
                   EJB 3.0 RC11 - FD

> runaway SLSB instance creation with ThreadLocalPool
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1031
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 08:54:01 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 20 Aug 2007 08:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1031) runaway SLSB
 instance creation with ThreadLocalPool
In-Reply-To: <13490824.1187375221041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30260272.1187614441101.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1031?page=comments#action_12372920 ] 
            
Carlo de Wolf commented on EJBTHREE-1031:
-----------------------------------------

Rev 64706: Fix for AS 4.2: Thread local pool is now backed by infinite pool to handle the life cycle of beans.

> runaway SLSB instance creation with ThreadLocalPool
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1031
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1031
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> Use of WeakThreadLocal vs ThreadLocal is the cause.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 09:03:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-461) Add
 highest_deliverable to NakreceiverWindow
In-Reply-To: <31148843.1175838778457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31956164.1187614981123.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-461?page=all ]

Bela Ban resolved JGRP-461.
---------------------------

    Resolution: Rejected

Not worth the additional complexity, and most likely no gains in performance

> Add highest_deliverable to NakreceiverWindow
> --------------------------------------------
>
>                 Key: JGRP-461
>                 URL: http://jira.jboss.com/jira/browse/JGRP-461
>             Project: JGroups
>          Issue Type: Sub-task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> Currently, we use highest_delivered (= removed) seqno, highest_deliverable would purge more messages faster, if we have a slow receiver (slow to call 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 lists.jboss.org  Mon Aug 20 09:03:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-281) NAKACK: merge
 sent_msgs, received_msgs and delivered_msgs into xmit_table
In-Reply-To: <5139686.1156505087158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22955514.1187614981272.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-281?page=all ]

Bela Ban closed JGRP-281.
-------------------------


> NAKACK: merge sent_msgs, received_msgs and delivered_msgs into xmit_table
> -------------------------------------------------------------------------
>
>                 Key: JGRP-281
>                 URL: http://jira.jboss.com/jira/browse/JGRP-281
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1, 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> NAKACK buffers sent messages in sent-table and received messages in received-table. We might be able to discard sent-table entirely because received-table will contain a message sent by oneself !
> Once we have loopback in place by default, we can be sure that any message sent by P will be in P's received-table.
> The new design is described in JGroups/doc/design.NAKACK.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 lists.jboss.org  Mon Aug 20 09:05:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-394) Performance
	enhancements
In-Reply-To: <27914397.1166549617965.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5549474.1187615101591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-394?page=comments#action_12372924 ] 
            
Bela Ban commented on JGRP-394:
-------------------------------

Checked GroupRequest and RequestCorrelator: they are already optimized

> Performance enhancements
> ------------------------
>
>                 Key: JGRP-394
>                 URL: http://jira.jboss.com/jira/browse/JGRP-394
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> - NAKACK.handleMessage(): NakReceiver.add() --> Retransmitter.add() --> TimeScheduler.add() is quite costly; we also iterate through a linear 
> list when removing a message from the Retransmitter !
> - Bundler: sending is over-synchronized; use ConcurrentHashMap for msgs
> - GroupRequest and RequestCorrelator eat CPU cycles in MessageDispatcher: remove 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 lists.jboss.org  Mon Aug 20 09:11:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-394) Performance
	enhancements
In-Reply-To: <27914397.1166549617965.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16683591.1187615461123.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-394?page=all ]

Bela Ban resolved JGRP-394.
---------------------------

    Resolution: Done

Looked at Bundler: we don't need a ConcurrentHashMap as access to msgs is very short and we need to synchronize anyway

> Performance enhancements
> ------------------------
>
>                 Key: JGRP-394
>                 URL: http://jira.jboss.com/jira/browse/JGRP-394
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> - NAKACK.handleMessage(): NakReceiver.add() --> Retransmitter.add() --> TimeScheduler.add() is quite costly; we also iterate through a linear 
> list when removing a message from the Retransmitter !
> - Bundler: sending is over-synchronized; use ConcurrentHashMap for msgs
> - GroupRequest and RequestCorrelator eat CPU cycles in MessageDispatcher: remove 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 lists.jboss.org  Mon Aug 20 10:00:13 2007
From: jira-events at lists.jboss.org (Jeff Johnson (JIRA))
Date: Mon, 20 Aug 2007 10:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2638377.1187618413665.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372937 ] 
            
Jeff Johnson commented on JBPM-1042:
------------------------------------

Hi,
The changes Tom made to GraphElement revision 1.12 included changes to conditionally lock the token in the execute() method look.  I believe those changes solve the problem my test case demonstrates.


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:04:11 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Mon, 20 Aug 2007 10:04:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1592) Backslashes
 not escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10341470.1187618651752.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=comments#action_12372940 ] 
            
Tobias Roth commented on JBPORTAL-1592:
---------------------------------------

No problem about the answering delay, it's not like you have an SLA with me :-)

I admit the problem is getting a bit confusing, I had to look through the whole forum post again myself. On top of that, I had a weird bug and couldn't start my portal anymore. I tried everything to find the cause of the problem, and then, just because I ran out of ideas, I reinstalled my jdk, and things worked again. D'oh.

Anyway, I'll try to explain my problem in different words (I'll also attach example files). I am using your ldif, the one with the jdukes you posted in the forum thread. I made a small modification: I removed the backslash and comma for jduke4, so I have a user to check if everything works without a comma.

Now, there are several jdukes, all of them with a comma in their name except my control user, jduke4. All of them are member of the "User" group.

I have this userSearchFilter: (&((uid={0})(objectClass=person)))
And this roleSearchFilter: (&((member={1})(objectClass=groupOfNames)))

With these filters, all jdukes can log in, but roles are only found for jduke4 (who has no comma in his DN), not for the other jdukes (who all have commas). Escaping the comma with three backslashes in the roleSearchFilter is all very well, but I cannot do that, because I want a filter that finds all jdukes, not just a specific one. It is that part of the jboss portal code that substitutes the {1} from the roleSearchFilter with does not properly escape commas, in my opinion.

I hope I could make this a bit more clear, it is indeed difficult to explain.

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 10:06:01 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Mon, 20 Aug 2007 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6819283.1187618761469.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=all ]

Tobias Roth updated JBPORTAL-1592:
----------------------------------

    Attachment: demo.ldif

ldif with demonstrates the issue (just like in the forum post, but with jduke4 comma removed)

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 10:06:01 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Mon, 20 Aug 2007 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13605367.1187618761826.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=all ]

Tobias Roth updated JBPORTAL-1592:
----------------------------------

    Attachment: ldap_identity-config.xml

ldap configuration to show problem

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 10:41:02 2007
From: jira-events at lists.jboss.org (Edward Staub (JIRA))
Date: Mon, 20 Aug 2007 10:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26990602.1187620862699.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12372946 ] 
            
Edward Staub commented on JBPM-1042:
------------------------------------

Sorry... I didn't read carefully enough, specifically:

    boolean actionMustBeLocked = (executionContext.getEvent()!=null)
                                 && (!token.isLocked());
                                        ^^^^^^^^^^^^^^^^^^^^

Yes, that looks like it would cure THIS problem.

I could be dreaming, but it seems like this might also mask real token-control "fights" on a thread that previously would have been detected by the lock.  I'm not sure the lock does anything at all now.  But I must admit that I don't understand what "fights" the lock was intended to detect in the first place.  It's clearly intra-thread, not inter-thread.  

FWIW, IMO, a better fix would be to get rid of the recursion.


> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:43:03 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 10:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1092) Invalid Java code
 generated from 'accumulate' function with nested classes
In-Reply-To: <22762348.1187266681169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26415894.1187620983639.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1092?page=all ]

Edson Tirelli closed JBRULES-1092.
----------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

Problem was that Class.getName() method returns the binary name of the class and Class.getCanonicalName() is a java 1.5 method. 
Implemented a helper function to generate the canonical name for 1.4 classes.

Unit test and integration tests added.

Thanks for reporting and providing test case.


> Invalid Java code generated from 'accumulate' function with nested classes
> --------------------------------------------------------------------------
>
>                 Key: JBRULES-1092
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1092
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Steps to reproduce:
> - Create a sample new project with the Eclipse plugin
> - Add following rule to the .drl file
> - Execute DroolsTest
> rule "AccumulateTest"
> 	no-loop true
> 	when
> 		$d: Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( total += $status ),
>                               result( total )
>                          )
> 	then
> 		System.out.println( "ok" ); 
> 		
> end
> Exception is:
> org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=AccumulateTest, agendaGroup=MAIN, salience=0, no-loop=true]
> 	com/sample/Rule_AccumulateTest_0.java (27:834) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (27:869) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : Syntax error, insert ";" to complete Statement
> 	com/sample/Rule_AccumulateTest_0.java (29:1027) : $status cannot be resolved
> 	com/sample/Rule_AccumulateTest_0.java (39:1483) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	com/sample/Rule_AccumulateTest_0.java (39:1518) : The nested type com.sample.DroolsTest$Message cannot be referenced using its binary name
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:64)
> 	at com.sample.DroolsTest.main(DroolsTest.java:21)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:51:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 10:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
In-Reply-To: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8681166.1187621461942.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1070?page=all ]

Edson Tirelli reassigned JBRULES-1070:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Exception with "not in" condition with  (int-values)
> ----------------------------------------------------
>
>                 Key: JBRULES-1070
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> // Bob wears plaid       
> Golfer( name == "Bob", 
>         $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
>         $bobsColor : color == "plaid",
>         color != $fredsColor, color != $joesColor,
>         color != $fredsNeighbourColor )
> yields the following exception
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
> 	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 10:51:02 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1070) Exception with
 "not in" condition with  (int-values)
In-Reply-To: <4698694.1186685221417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13208374.1187621462196.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1070?page=all ]

Edson Tirelli closed JBRULES-1070.
----------------------------------

    Resolution: Duplicate Issue

This was fixed as part of:

http://jira.jboss.com/jira/browse/JBRULES-1073


> Exception with "not in" condition with  (int-values)
> ----------------------------------------------------
>
>                 Key: JBRULES-1070
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1070
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.2
>            Reporter: Dr. Gernot Starke
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> // Bob wears plaid       
> Golfer( name == "Bob", 
>         $bobsPosition : position not in ($fredsPosition, $joesPosition, $fredsNeighbourPosition),                                                  
>         $bobsColor : color == "plaid",
>         color != $fredsColor, color != $joesColor,
>         color != $fredsNeighbourColor )
> yields the following exception
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.AbstractCompositeRestriction$CompositeContextEntry.updateFromTuple(AbstractCompositeRestriction.java:112)
> 	at org.drools.common.QuadroupleBetaConstraints.updateFromTuple(QuadroupleBetaConstraints.java:178)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:115)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at arc42.drools.samples.golfer.GolfingExample.main(GolfingExample.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 11:14:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <633499.1187622841308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-577?page=all ]

Bela Ban reopened JGRP-577:
---------------------------

             
[mail by Brian Campbell]
These logs were produced  as follows:

Server A comes up first and stays up the whole time.  B comes up with
the wrong credentials and, the first time, gets the join rejection/auth
failure message from A and throws the SecurityException on its side.  I
ctrl-c kill B.  Then start B again and it falls into the join timeout
loop.  Ctrl-C will no longer stop the process so I have to kill -9 it.
Finally I start B one more time - this time with the correct credentials
and it ends up in a similar join timeout loop.   

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>         Attachments: a.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Mon Aug 20 11:14:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15486192.1187622841442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-577?page=all ]

Bela Ban updated JGRP-577:
--------------------------

    Attachment: a.log

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>         Attachments: a.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Mon Aug 20 11:16:01 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 11:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18785943.1187622961196.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-577?page=all ]

Bela Ban updated JGRP-577:
--------------------------

    Attachment: b.log

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>         Attachments: a.log, b.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Mon Aug 20 12:43:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 12:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
In-Reply-To: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26018802.1187628181297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1058?page=all ]

Edson Tirelli reassigned JBRULES-1058:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> nested accessors with Sets - "not contains" is not a valid operator for MVEL
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-1058
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark McNally
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Following does not work:
> 		rule StateMatch
> 			when
> 			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
> 			then 	
> 				retract( $ca );
> 		end
> 		
> 		
> 		public class CandidateAssociation {
> 			private PatientDetails patientDetails;
> 			private NurseDetails   nurseDetails;
> 			private int overlapHours;
> 		
> 			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
> 				super();
> 				this.patientDetails = patientDetails;
> 				this.nurseDetails = nurseDetails;
> 				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
> 			}
> 		    [...]
> 		}
> 		
> 		public class NurseDetails {
> 			private Set stateLicensures = new HashSet();
> 			[...]
> 		}
> 		public class PatientDetails {
> 			private String state;
> 			[...]
> 		}
> Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 
> Also Noticed that the following workaround did not work:
> 		rule State
> 		    dialect "mvel"
> 			when
> 		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
> 			then 	
> 		  	    retract( $ca );
> 		end
> 		
> 		This produced this Exception:
> 		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
> 	        at org.drools.rule.Package.checkValidity(Package.java:408)
> 	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	        at [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 13:02:01 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Aug 2007 13:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1083) Brackets are
 not always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <396606.1187629321231.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1083?page=comments#action_12372969 ] 
            
Edson Tirelli commented on JBRULES-1083:
----------------------------------------

I think for this case we should fix documentation only and keep parser behavior as it is right now, i.e., for "not" and "exists", the brackets are option only if they are followed by a single pattern. 

The current grammar rules are:

LHS_NOT::= 'not' ( '(' <conditional_element> ')' ) | <pattern>
LHS_EXISTS::= 'exists' ( '(' <conditional_element> ')' ) | <pattern>

So, the following is valid:

not Bus()
not ( Bus() )  // brackets are optional for single pattern.

Any other following conditional element will require the brackets. Following are all valid:

not( Bus() and Driver() )
not( Bus() from $buses )
not( Bus() and not Driver() )
not( Bus() and not( Driver() ) )

Please note that the following is valid and require the ():

not( exists( Bus() ) )

But the above is Semantically EQUIVALENT as:

not( Bus() )



> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Mark Proctor
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 13:11:12 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 13:11:12 -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: <16979760.1187629872791.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 GA
                       (was: jBPM BPEL 1.2 GA)

Upon deployment, the web service module finds the latest version of the process definition *at that time*. Picking up the latest version of the process definition is not generally possible because the WSDL interfaces might have changed. The WSEE specification assumes the WSDL description to be immutable; therefore, no API exists to modify it at runtime. The safe, clean path to pick up the newly deployed version of the process definition is to redeploy the web service module as well.

> 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 GA
>
>
> 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 lists.jboss.org  Mon Aug 20 13:13:01 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 13:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (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: <26015203.1187629981197.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-200?page=all ]

Alejandro Guizar resolved BPEL-200.
-----------------------------------

    Resolution: Done

SOLUTION Redeploy the web module along with the process archive.

> 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 GA
>
>
> 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 lists.jboss.org  Mon Aug 20 14:00:01 2007
From: jira-events at lists.jboss.org (Anders Persson (JIRA))
Date: Mon, 20 Aug 2007 14:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
Message-ID: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>

It is possible to create a deadlock when trying to close a channel which is not yet connected
---------------------------------------------------------------------------------------------

                 Key: JGRP-578
                 URL: http://jira.jboss.com/jira/browse/JGRP-578
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
         Environment: Windows XP; java 1_5_0_12
            Reporter: Anders Persson
         Assigned To: Bela Ban


The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.

Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Mon Aug 20 14:04:01 2007
From: jira-events at lists.jboss.org (Michael Ihde (JIRA))
Date: Mon, 20 Aug 2007 14:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-923) Creating
 queue/topic with
 JNDI subcontexts fails, e.g. names such as queue/foo/bar
In-Reply-To: <16664219.1173999154492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18621300.1187633041693.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-923?page=comments#action_12372977 ] 
            
Michael Ihde commented on JBMESSAGING-923:
------------------------------------------

What is the status on this, are there plans to fix it?

> Creating queue/topic with JNDI subcontexts fails, e.g. names such as queue/foo/bar
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-923
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-923
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Elias Ross
>
> The following service.xml will generate an exception:
> <server>
>    <loader-repository>
>         jboss.messaging:loader=ScopedLoaderRepository
>         <loader-repository-config>
>                 java2ParentDelegation=false
>         </loader-repository-config>
>    </loader-repository>
>    <mbean code="org.jboss.jms.server.destination.QueueService"
>         name="jboss.messaging.destination:service=Queue,name=ppm/mt"
>         xmbean-dd="xmdesc/Queue-xmbean.xml">
>         <depends optional-attribute-name="ServerPeer">jboss.messaging:service=Se
> rverPeer</depends>
>       <depends>jboss.messaging:service=PostOffice</depends>
>    </mbean>
> </server>
> 15:46:12,205 ERROR [ExceptionUtil] Queue[/queue/ppm/bridge/mqube, name=ppm/bridg
> e/mqube] startService
> javax.naming.NameNotFoundException: ppm 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.rebind(NamingServer.java:165)
>         at org.jnp.server.NamingServer.rebind(NamingServer.java:168)
>         at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:510)
>         at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:477)
>         at org.jboss.jms.server.DestinationJNDIMapper.registerDestination(Destin
> ationJNDIMapper.java:146)
>         at org.jboss.jms.server.destination.QueueService.startService(QueueServi
> ce.java:142)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 16:01:43 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 16:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1054) DSL-Editor: "Add"
 button does not work
In-Reply-To: <6877229.1186040449403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11549110.1187640103869.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1054?page=all ]

Fernando Meyer closed JBRULES-1054.
-----------------------------------

    Resolution: Out of Date

It's already fixed for 4.0.1

> DSL-Editor: "Add" button does not work
> --------------------------------------
>
>                 Key: JBRULES-1054
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1054
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse-IDE: DSL-Editor
>            Reporter: Peter Bomben
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Revision 13935: "Add" button in DSL-Editor without function. To add DSLs you either have to change to the text editor and manually add new lines to the .dsl-file or use the copy feature to create a new line from an existing 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 lists.jboss.org  Mon Aug 20 16:01:44 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 16:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1028) importing
 .brxml into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18866195.1187640104174.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=comments#action_12373005 ] 
            
Fernando Meyer commented on JBRULES-1028:
-----------------------------------------

Michael, Should I move the brl and rulemodel to compiler? I think thats the only way to do for drools-ant don't depends from brms.

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Mon Aug 20 16:20:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 16:20:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-216) eclipse bpel designer
	integration
In-Reply-To: <14006792.1166405259742.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15849142.1187641219052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-216?page=all ]

Alejandro Guizar updated BPEL-216:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1 GA
                       (was: jBPM BPEL 1.2 GA)

> eclipse bpel designer integration
> ---------------------------------
>
>                 Key: BPEL-216
>                 URL: http://jira.jboss.com/jira/browse/BPEL-216
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> Enable one-step deployment of a bpel process + interface wsdl definitions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 16:20:19 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 16:20:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-190) webservice
 descriptors generation tool
Message-ID: <9703418.1187641219643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-190?page=all ]

Alejandro Guizar updated BPEL-190:
----------------------------------

        Fix Version/s: jBPM BPEL 1.1 GA
                           (was: jBPM BPEL 1.2 GA)
    Affects Version/s:     (was: jBPM BPEL 1.1 beta 1)

> webservice descriptors 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
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> 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 lists.jboss.org  Mon Aug 20 16:22:22 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 20 Aug 2007 16:22:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-398) NullPointer when
	weaving a jar
Message-ID: <29684794.1187641342482.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointer when weaving a jar
------------------------------

                 Key: JBBUILD-398
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-398
             Project: JBoss Build System
          Issue Type: Bug
          Components: JBossRetro
            Reporter: Paul Gier
         Assigned To: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


When weaving a jar file, a null pointer exception is thrown if the outputDirectory parameter is null.  The weaver should be able to use the outputJar path.
As a workaround, both the outputDirectory and outputJar parameters should be set to the jar path when weaving a jar 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 lists.jboss.org  Mon Aug 20 16:26:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 20 Aug 2007 16:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-398) NullPointer when
	weaving a jar
In-Reply-To: <29684794.1187641342482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22412028.1187641578236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-398?page=all ]

Paul Gier closed JBBUILD-398.
-----------------------------

    Resolution: Done

> NullPointer when weaving a jar
> ------------------------------
>
>                 Key: JBBUILD-398
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-398
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: JBossRetro
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: JBossRetro-1.1.3.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> When weaving a jar file, a null pointer exception is thrown if the outputDirectory parameter is null.  The weaver should be able to use the outputJar path.
> As a workaround, both the outputDirectory and outputJar parameters should be set to the jar path when weaving a jar 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 lists.jboss.org  Mon Aug 20 17:09:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Mon, 20 Aug 2007 17:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-276) generate bpel
 application descriptor along with wsdl service description
Message-ID: <23516822.1187644158226.JavaMail.jira@cloud.prod.atl2.jboss.com>

generate bpel application descriptor along with wsdl service description
------------------------------------------------------------------------

                 Key: BPEL-276
                 URL: http://jira.jboss.com/jira/browse/BPEL-276
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Engine
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.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 lists.jboss.org  Mon Aug 20 17:11:19 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1592) Backslashes
 not escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14406742.1187644279099.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=comments#action_12373013 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1592:
-----------------------------------------------

Ok, few things here:

1) Your configuration was wrong
 - {1} does nothing. Only {0} is valid for roleSearchFilter
 - instead of '(&((member={1})(objectClass=groupOfNames))) ' it should be '(&((cn={0})(objectClass=groupOfNames)))'

Simply you are mixing two things here. RoleModule is responsible only for resolving roles and not user/role relationship. For this you should use proper MembershipModule (LDAPStaticGroupMembershipModuleImpl or LDAPStaticRoleMembershipModuleImpl) and correct 'membershipAttributeID' and 'membershipAttributeIsDN' (see in doc or look into standardidentity-config.xml file). Its all in the docs

2) Still... the issue you described was present, and the solution you proposed was quite a good one :) I was just missing proper use case to make valid test case. Currently uid  'jduke4, Duke' is part of testsuite. I also tested manualy with attached ldif.

Thanks!




> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 17:15:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1592) Backslashes not
 escaped correctly with ldap modules
In-Reply-To: <25418937.1184673647422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22162184.1187644518924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1592?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1592.
-------------------------------------------

    Resolution: Done

fixed. commited to JBoss_Portal_Branch_2_6.

> Backslashes not escaped correctly with ldap modules
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1592
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1592
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: demo.ldif, ldap_identity-config.xml
>
>
> LDAPRoleModule and LDAPExtRoleModule don't find roles associated with users, if the users DN contains a backslash, as it is frequent with Microsoft Active Directory.
> Example logfile excerpts and are given in the forum.
> I added a simple  filter = filter.replaceAll("\\\\", "\\\\\\\\"); in one place in LDAPExtRoleModuleImpl.java which fixed the thing for me. However, not knowing much of java, I don't know the correct place to add this, so that all cases are fixed.
> 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 lists.jboss.org  Mon Aug 20 17:21:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1561) google widget
 preferences cannot be updated after window creation
In-Reply-To: <25873473.1184018208231.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5007459.1187644878776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1561?page=all ]

Boleslaw Dawidowicz updated JBPORTAL-1561:
------------------------------------------

    Fix Version/s: 2.6.3 Final
                       (was: 2.6.2 Final)
         Priority: Minor  (was: Major)

this can wait 

> google widget preferences cannot be updated after window creation
> -----------------------------------------------------------------
>
>                 Key: JBPORTAL-1561
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1561
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>    Affects Versions: 2.6.1 Final, 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.3 Final
>
>
> 1) add a google widget window to the page
> 2) go to AdminPortlet, navigate and click on the portlet window you added
> 3) there is edit window with widget preferences 
> 4) changing values and hitting 'update' does nothing

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 17:25:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Mon, 20 Aug 2007 17:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1640) provide OpenSSO
	integration
Message-ID: <21988026.1187645118595.JavaMail.jira@cloud.prod.atl2.jboss.com>

provide OpenSSO integration
---------------------------

                 Key: JBPORTAL-1640
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1640
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.2 Final, 2.8 Final


Provide integration with OpenSSO using tomcat valve mechanism

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 17:40:51 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Aug 2007 17:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
In-Reply-To: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4327739.1187646051475.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-578?page=all ]

Bela Ban updated JGRP-578:
--------------------------

    Fix Version/s: 2.6

> It is possible to create a deadlock when trying to close a channel which is not yet connected
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-578
>                 URL: http://jira.jboss.com/jira/browse/JGRP-578
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1_5_0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.
> Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Mon Aug 20 19:05:18 2007
From: jira-events at lists.jboss.org (Anh Vuong (JIRA))
Date: Mon, 20 Aug 2007 19:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3828433.1187651118705.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1086?page=comments#action_12373031 ] 
            
Anh Vuong commented on JBRULES-1086:
------------------------------------

if custom classs loader does not call definePackage, then Class.getPackage() may return null. Is it possible to put the following code in the place of the commented line:
 
//String pkgName = (pkg != null) ? pkg.getName() : "";

String pkgName = "";
if (pkg == null) {
    int index = clazz.getName().lastIndexOf('.');
    if (index != -1)
        pkgName = clazz.getName().substring(0, index);
}
else 
    pkgName = pkg.getName();


> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 19:38:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 20 Aug 2007 19:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-821) ValueList in rule
	model
In-Reply-To: <19103957.1177544080454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24404213.1187653098347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-821?page=all ]

Michael Neale updated JBRULES-821:
----------------------------------

          Component/s: drools-brms
        Fix Version/s: 4.0.1
    Affects Version/s:  4.0.0.GA

> ValueList in rule model
> -----------------------
>
>                 Key: JBRULES-821
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-821
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>         Attachments: jbrmsDropDown.doc
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 20:50:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1089) Getting "could
 not access property ('=')" for a valid rule.
In-Reply-To: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24117729.1187657418691.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1089?page=all ]

Mark Proctor updated JBRULES-1089:
----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Getting "could not access property ('=')" for a valid rule.
> -----------------------------------------------------------
>
>                 Key: JBRULES-1089
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
>            Reporter: Arsalan Zaidi
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
> Sent: 13 August 2007 22:16
> To: Rules Users List
> Subject: Re: [rules-users] could not access property ('=')
> Attachments: ATT426765.txt
>    This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?
>    Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 
> when
>            $dto : DTO( )
>            W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1
> then
>    Thanks, and hope it helps.
>    Edson
> 2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
>   Hi.
>   I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.
>   I have a rule which looks like this:
>   rule "W250.42 Editable"
>         when
>               DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )
>         then
>               System.out.println ("0" );
>               Action action = createAction("W250.42" , false , true );
>               retList.add(action); 
>   end 
>   both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .
>   Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.
>   org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )
>         at org.drools.reteoo.Rete.assertObject(Rete.java:168 )
>         at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 
>         at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )
>         at com.sample.DroolsTest.main( DroolsTest.java:34)
>   Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )
>         at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )
>         at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )
>         at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)
>         at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 
>         at org.mvel.MVEL.executeExpression( MVEL.java:202)
>         at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )
>         ... 10 more
>   Caused by: org.mvel.PropertyAccessException: could not access property ('=') 
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )
>         ... 18 more
>   If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.
>   I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')
>   What seems to be the issue?
>   Thanks in advance!
>   Regards,
>   --Arsalan
>         This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 
>        
>   _______________________________________________
>   rules-users mailing list
>   rules-users at lists.jboss.org 
>   https://lists.jboss.org/mailman/listinfo/rules-users
> -- 
>   Edson Tirelli
>   Software Engineer - JBoss Rules Core Developer
>   Office: +55 11 3529-6000
>   Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat @ www.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 lists.jboss.org  Mon Aug 20 20:50:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2098042.1187657418888.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=all ]

Mark Proctor updated JBRULES-1091:
----------------------------------

    Fix Version/s: 4.0.1

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Mon Aug 20 20:50:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1102) Bug in
 DefaultBetaConstraint class indexing to never turn on
In-Reply-To: <22237245.1187501761200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27672389.1187657419045.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1102?page=all ]

Mark Proctor updated JBRULES-1102:
----------------------------------

    Fix Version/s: 4.0.1

> Bug in DefaultBetaConstraint class indexing to never turn on
> ------------------------------------------------------------
>
>                 Key: JBRULES-1102
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1102
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Look at line 75 of DefaultBetaConstraint: notice the (depth <= this.indexed). This will always evaluate to false. It should be this.indexed < depth
> This bug and the one reported here (http://jira.jboss.com/jira/browse/JBRULES-1101) make sure that indexing is not used 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 lists.jboss.org  Mon Aug 20 20:50:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:50:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10568278.1187657419232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1101?page=all ]

Mark Proctor updated JBRULES-1101:
----------------------------------

    Fix Version/s: 4.0.1

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 20:52:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 20 Aug 2007 20:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1102) Bug in
 DefaultBetaConstraint class indexing to never turn on
In-Reply-To: <22237245.1187501761200.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8574688.1187657538292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1102?page=all ]

Mark Proctor closed JBRULES-1102.
---------------------------------

    Resolution: Done

This is fixed, please use the latest snapshot, as there is more wrong with this class than just the depth check you noticed.

> Bug in DefaultBetaConstraint class indexing to never turn on
> ------------------------------------------------------------
>
>                 Key: JBRULES-1102
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1102
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> Look at line 75 of DefaultBetaConstraint: notice the (depth <= this.indexed). This will always evaluate to false. It should be this.indexed < depth
> This bug and the one reported here (http://jira.jboss.com/jira/browse/JBRULES-1101) make sure that indexing is not used 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 lists.jboss.org  Mon Aug 20 22:23:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 22:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15503991.1187662998502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1053?page=all ]

Fernando Meyer reassigned JBRULES-1053:
---------------------------------------

    Assignee: Fernando Meyer  (was: Edson Tirelli)

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 20 23:00:50 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Mon, 20 Aug 2007 23:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1053) Import collision
 when static inner classes of 2 different classes have same name
In-Reply-To: <11800382.1185984889393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29554333.1187665250406.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1053?page=all ]

Fernando Meyer closed JBRULES-1053.
-----------------------------------

    Resolution: Won't Fix

Hi Eric, after some tests I noticed that in java language you can't import the same class name twice even if the class is defined in different packages, ie try creating a java file and import both import java.awt.List; import java.util.List; It won't work, you will get a similar error from javac compiler

So you can try using two package builders as I did in the following example 

    public void testImportColision () throws Exception  { 
        final PackageBuilder builder = new PackageBuilder();
        final PackageBuilder builder2 = new PackageBuilder();
        builder.addPackageFromDrl( new InputStreamReader( getClass().getResourceAsStream( "nested1.drl" ) ) );
        builder2.addPackageFromDrl( new InputStreamReader( getClass().getResourceAsStream( "nested2.drl" ) ) );
        final Package pkg = builder.getPackage();
        final Package pkg2 = builder2.getPackage();
 
        final RuleBase ruleBase = getRuleBase();
        ruleBase.addPackage( pkg );
        ruleBase.addPackage( pkg2 );
 
 
        final WorkingMemory workingMemory = ruleBase.newStatefulSession();
 
        workingMemory.insert( new FirstClass() );
        workingMemory.insert( new SecondClass() );
        workingMemory.insert( new FirstClass.AlternativeKey() );
        workingMemory.insert( new SecondClass.AlternativeKey() );
 
        workingMemory.fireAllRules();
    }

> Import collision when static inner classes of 2 different classes have same name
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-1053
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1053
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Fedora 7, JSE 1.5.0_12, Eclipse 3.3
>            Reporter: Eric Miles
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>         Attachments: drools-import-collision-test.tar.gz
>
>
> I have 2 drl files, each that deals with a particular class (FirstClass and SecondClass).  Both of these class have public static inner classes with the same name (AlternativeKey).  When attempting to compile these 2 DRL files together, I get an import collision error.  I am attaching a test case that is a maven and Eclipse project.  There is a junit test case written to show what happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 00:14:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Aug 2007 00:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1038) Client side
 failover hopping does not work
In-Reply-To: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6280517.1187669658304.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1038?page=all ]

Clebert Suconic updated JBMESSAGING-1038:
-----------------------------------------

    Affects Version/s: 1.4.0.CR1

> Client side failover hopping does not work
> ------------------------------------------
>
>                 Key: JBMESSAGING-1038
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.
> if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".
> Instead it should iterate through the list of delegates trying each one in turn.
> Need to write a test for this 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 lists.jboss.org  Tue Aug 21 00:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Aug 2007 00:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5422455.1187670258397.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1027?page=comments#action_12373049 ] 
            
Clebert Suconic commented on JBMESSAGING-1027:
----------------------------------------------

Update: There is one test I still have to write for this client... validating when a client is killed.

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 01:59:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 01:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1090) Simple data field
	enums in BRMS
In-Reply-To: <21981533.1187257381183.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30353098.1187675958400.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1090?page=all ]

Michael Neale closed JBRULES-1090.
----------------------------------

    Resolution: Done

> Simple data field enums in BRMS
> -------------------------------
>
>                 Key: JBRULES-1090
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1090
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Can use MVEL (or something) to store (as a discrete asset) a mapping of fact/fields to value lists. Then these value lists can be used in the Guided editor. 
> eg:
> Person.age : [1, 2, 3, 4, 5, 6, 7]
> Person.sex: [M, F]
> Person.classification: [ HIGH, LOW]
> these are then used to drive drop downs. 
> For extra bonus points, provide a means to display a different value to what is rendered. 
> This can then be loaded as a separate map into SCE and loaded up to the client for display as 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 lists.jboss.org  Tue Aug 21 01:59:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 01:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-821) ValueList in rule
	model
In-Reply-To: <19103957.1177544080454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19254068.1187675958577.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-821?page=all ]

Michael Neale closed JBRULES-821.
---------------------------------

    Resolution: Done

> ValueList in rule model
> -----------------------
>
>                 Key: JBRULES-821
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-821
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>         Attachments: jbrmsDropDown.doc
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 03:39:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 03:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22495141.1187681958552.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12373057 ] 
            
Michael Neale commented on JBRULES-1060:
----------------------------------------

yes I can run this to completion if I give it -Xmx500M (not sure what else will work, I just tried it):

Something is up
Run time (milliseconds): 21100
Finished problem at Tue Aug 21 17:41:11 EST 2007

This is a combination explosion, but it certainly works. In my case, I didn't see an OOME reported as well (on Linux, Fedora 7, JSE5). I will try on the mac as well, but it seems in some cases OOME is being swallowed somehow before it is being reported. Perhaps command line it wil show it (I was running it from within eclipse).

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Tue Aug 21 03:49:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 03:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22629492.1187682558372.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12373061 ] 
            
Michael Neale commented on JBRULES-1060:
----------------------------------------

Yes I have checked the code, there is nowhere we catch Throwable that may be the cause of this non reporting of OOME that I can see. 

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Tue Aug 21 04:16:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 04:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-579) New property:
	bind_interface
Message-ID: <28281953.1187684178395.JavaMail.jira@cloud.prod.atl2.jboss.com>

New property: bind_interface
----------------------------

                 Key: JGRP-579
                 URL: http://jira.jboss.com/jira/browse/JGRP-579
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


bind_addr tells JGroups which interface to bind to. However, if an IP address has more than 1 interface, e.g. in the case of IP Bonding, the JDK simply picks the first interface.
Similarly, if a given interface has more than 1 associated InetAddress, we simply pick the first.

Adding a property bind_interface (-Djgroups.bind_interface) allows us to exactly pick the correct network interface in both cases above.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:08:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 05:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-579) New property:
	bind_interface
In-Reply-To: <28281953.1187684178395.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14992167.1187687298243.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-579?page=all ]

Bela Ban resolved JGRP-579.
---------------------------

    Resolution: Done

> New property: bind_interface
> ----------------------------
>
>                 Key: JGRP-579
>                 URL: http://jira.jboss.com/jira/browse/JGRP-579
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> bind_addr tells JGroups which interface to bind to. However, if an IP address has more than 1 interface, e.g. in the case of IP Bonding, the JDK simply picks the first interface.
> Similarly, if a given interface has more than 1 associated InetAddress, we simply pick the first.
> Adding a property bind_interface (-Djgroups.bind_interface) allows us to exactly pick the correct network interface in both cases above.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:25:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3415) Port RARDeployer
In-Reply-To: <11713167.1153692311447.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28823824.1187688318379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3415?page=all ]

Dimitris Andreadis updated JBAS-3415:
-------------------------------------

    Assignee:     (was: Weston Price)
    Priority: Critical  (was: Major)

> Port RARDeployer
> ----------------
>
>                 Key: JBAS-3415
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3415
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Deployment services
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The RARDeployer needs to be ported or rewritten for the new VDF

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:25:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3412) Port ClientDeployer
 and complete JavaEE5 support
In-Reply-To: <30460334.1153691831496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1358255.1187688318600.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3412?page=all ]

Dimitris Andreadis updated JBAS-3412:
-------------------------------------

    Priority: Critical  (was: Major)

> Port ClientDeployer and complete JavaEE5 support
> ------------------------------------------------
>
>                 Key: JBAS-3412
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3412
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The ClientDeployer needs to be ported to the new VDF and the JavaEE 5 changes 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 lists.jboss.org  Tue Aug 21 05:41:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 21 Aug 2007 05:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-218) make the imported
 wsdl documents a source of partner service descriptions
In-Reply-To: <17113795.1166408025580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33352088.1187689278525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-218?page=all ]

Alejandro Guizar updated BPEL-218:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1 GA
                       (was: jBPM BPEL 1.2 GA)

> make the imported wsdl documents a source of partner service descriptions
> -------------------------------------------------------------------------
>
>                 Key: BPEL-218
>                 URL: http://jira.jboss.com/jira/browse/BPEL-218
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, WSDL documents imported by a process are not examined during resolution of partner services, because an alternate, dynamic service catalog (e.g. an XML registry) is expected to be in place. However, in simple scenarios, such as deployment from the designer, no alternate catalog exists. The only source of partner service descriptions is the imported WSDL documents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 05:52:19 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:52:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3766) Port the webservice
	deployer
In-Reply-To: <28538797.1160804141717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9311207.1187689939836.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3766?page=all ]

Dimitris Andreadis updated JBAS-3766:
-------------------------------------

    Priority: Critical  (was: Major)

> Port the webservice deployer
> ----------------------------
>
>                 Key: JBAS-3766
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3766
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>         Assigned To: Thomas Diesler
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The old jmx/interceptor based jbossws deployer is now complete broken:
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.ws:service=DeployerInterceptorEJB21
>  -> jboss.ejb:service=EJBDeployer{Create:** NOT FOUND **}
>  -> jboss.ejb:service=EJBDeployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorEJB3
>  -> jboss.ejb3:service=EJB3Deployer{Create:** NOT FOUND **}
>  -> jboss.ejb3:service=EJB3Deployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorNestedJSE
>  -> jboss.ws:service=WebServiceDeployerJSE{Start:Configured}
>  -> jboss.ws:service=WebServiceDeployerJSE{Create:Configured}
> jboss.ws:service=WebServiceDeployerJSE
>  -> jboss.web:service=WebServer{Start:** NOT FOUND **}
>  -> jboss.web:service=WebServer{Create:** NOT FOUND **}
> *** CONTEXTS IN ERROR: Name -> Error
> jboss.web:service=WebServer -> ** NOT FOUND **
> jboss.ejb3:service=EJB3Deployer -> ** NOT FOUND **
> jboss.ejb:service=EJBDeployer -> ** NOT FOUND **
> It needs to be ported to a deployer that augments the metadata passed to other deployers. This means no unapckaing of wars to modify the war 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 lists.jboss.org  Tue Aug 21 05:54:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 05:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3768) Define initial
 persistent format of the profile repository
In-Reply-To: <6622737.1160958581689.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4541043.1187690058230.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3768?page=all ]

Dimitris Andreadis updated JBAS-3768:
-------------------------------------

    Priority: Critical  (was: Major)

> Define initial persistent format of the profile repository
> ----------------------------------------------------------
>
>                 Key: JBAS-3768
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3768
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> We need to define the initial profile repository format with consideration of future migrations, jsr88, admin tools.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:08:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3766) Port the webservice
	deployer
In-Reply-To: <28538797.1160804141717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17110736.1187690898353.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3766?page=all ]

Thomas Diesler resolved JBAS-3766.
----------------------------------

    Resolution: Done

Resolved with jbossws-2.0.1

> Port the webservice deployer
> ----------------------------
>
>                 Key: JBAS-3766
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3766
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>         Assigned To: Thomas Diesler
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> The old jmx/interceptor based jbossws deployer is now complete broken:
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> jboss.ws:service=DeployerInterceptorEJB21
>  -> jboss.ejb:service=EJBDeployer{Create:** NOT FOUND **}
>  -> jboss.ejb:service=EJBDeployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorEJB3
>  -> jboss.ejb3:service=EJB3Deployer{Create:** NOT FOUND **}
>  -> jboss.ejb3:service=EJB3Deployer{Start:** NOT FOUND **}
> jboss.ws:service=DeployerInterceptorNestedJSE
>  -> jboss.ws:service=WebServiceDeployerJSE{Start:Configured}
>  -> jboss.ws:service=WebServiceDeployerJSE{Create:Configured}
> jboss.ws:service=WebServiceDeployerJSE
>  -> jboss.web:service=WebServer{Start:** NOT FOUND **}
>  -> jboss.web:service=WebServer{Create:** NOT FOUND **}
> *** CONTEXTS IN ERROR: Name -> Error
> jboss.web:service=WebServer -> ** NOT FOUND **
> jboss.ejb3:service=EJB3Deployer -> ** NOT FOUND **
> jboss.ejb:service=EJBDeployer -> ** NOT FOUND **
> It needs to be ported to a deployer that augments the metadata passed to other deployers. This means no unapckaing of wars to modify the war 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 lists.jboss.org  Tue Aug 21 06:14:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4898924.1187691258259.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4562?page=all ]

Dimitris Andreadis updated JBAS-4562:
-------------------------------------

    Priority: Critical  (was: Major)

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:18:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4832600.1187691509198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4563?page=all ]

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Priority: Critical  (was: Major)

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:18:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17829096.1187691509397.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4563?page=all ]

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:18:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4564) Hibernate
	EntityManager 3.3.2
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8557370.1187691509575.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4564?page=all ]

Dimitris Andreadis updated JBAS-4564:
-------------------------------------

      Component/s: Hibernate service
    Fix Version/s:  JBossAS-5.0.0.Beta3
         Priority: Critical  (was: Major)

> Hibernate EntityManager 3.3.2
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:35:35 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 21 Aug 2007 06:35:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4565) Resolve the issue
 of Hibernate Validator
In-Reply-To: <16152273.1184779067941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30719129.1187692535930.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4565?page=comments#action_12373086 ] 
            
Dimitris Andreadis commented on JBAS-4565:
------------------------------------------

Link to Validator: http://www.hibernate.org/412.html

> Resolve the issue of Hibernate Validator
> ----------------------------------------
>
>                 Key: JBAS-4565
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4565
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Emmanuel Bernard
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:37:18 2007
From: jira-events at lists.jboss.org (Shahad Ahmed (JIRA))
Date: Tue, 21 Aug 2007 06:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
Message-ID: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>

Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
----------------------------------------------------------------------------------------------

                 Key: JBRULES-1106
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Windows XP SP2, Sun JRE 1.5_09
            Reporter: Shahad Ahmed
         Assigned To: Mark Proctor


I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.

Here's how to replicate the problem for a clean BRMS install:

1. Create a new category called test.

2. In the defaultPackage create a new DSL called test as shown below:

[when]true=eval(true)
[then]report=System.out.println("Hello");

3. Save the test DSL

4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.

5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".

6. Save rule test1.

7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.

8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).

9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.

10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).

package defaultPackage

rule "test1"
	dialect "java"
	when
	eval(true)
	then
	System.out.println("Hello");
end

rule "test1"
	dialect "java"
	when
	eval(true)
	then
	System.out.println("Hello");
end

Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:40:28 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:40:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3277) Webservices tests
 deployment exceptions in jboss-head testsuite
Message-ID: <23871124.1187692828863.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3277?page=all ]

Thomas Diesler resolved JBAS-3277.
----------------------------------

    Fix Version/s:     (was:  JBossAS-5.0.0.Beta3)
       Resolution: Cannot Reproduce Bug

Cannot reproduce with jbossws-2.0.1.GA

tests-webservice:
    [junit] Running org.jboss.test.webservice.admindevel.ExampleTestCase
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 19.304 sec
    [junit] Running org.jboss.test.webservice.admindevel.ExplodedExampleTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.929 sec
    [junit] Running org.jboss.test.webservice.admindevel.RedeployExampleTestCase
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 8.35 sec


> Webservices tests deployment exceptions in jboss-head testsuite
> ---------------------------------------------------------------
>
>                 Key: JBAS-3277
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3277
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Rajesh Rajasekaran
>         Assigned To: Thomas Diesler
>
> All webservices tests in the jboss-head testsuite are unable to deploy the test resources.
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060531155015/testsuite/output/log/test.log
> The DeplomentException stack trace is given below.
> org.jboss.deployment.DeploymentException: Could not create deployment: file:/services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/output/lib/ws4ee-admindevel.jar; - nested throwable: (java.lang.NoClassDefFoundError: org/jboss/webservice/metadata/jaxrpcmapping/MethodParamPartsMapping)
> 	at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:53)
> 	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:975)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
> 	at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:560)
>         ..................................
> Caused by: java.lang.NoClassDefFoundError: org/jboss/webservice/metadata/jaxrpcmapping/MethodParamPartsMapping
> 	at org.jboss.ws.server.WebServiceDeployerEJB21.createWebServicesMetaData(WebServiceDeployerEJB21.java:110)
> 	at org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:103)
> 	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: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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:40:29 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 06:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-441) TP.loopback might
 cause some issues with incorrectly purged messages in STABLE
In-Reply-To: <31577745.1174304855268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1432257.1187692829171.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-441?page=all ]

Bela Ban resolved JGRP-441.
---------------------------

    Resolution: Cannot Reproduce Bug

This was most likely an issue in STABLE (fixed in 2.5) and not with loopback

> TP.loopback might cause some issues with incorrectly purged messages in STABLE
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-441
>                 URL: http://jira.jboss.com/jira/browse/JGRP-441
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Investigate, I've seen this a few times, but only when loopback was enabled.
> Workaround is always to leave loopback off (default 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 lists.jboss.org  Tue Aug 21 06:42:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 06:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-155) TP.loopback should
	always be used
Message-ID: <9478559.1187692938352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-155?page=all ]

Bela Ban updated JGRP-155:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Not sure this is relevant any longer

> TP.loopback should always be used
> ---------------------------------
>
>                 Key: JGRP-155
>                 URL: http://jira.jboss.com/jira/browse/JGRP-155
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9, 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> Investigate the 3 potential problem areas below:
> - Memory leak caused by FC when credits are received too quickly
> - Deadlocks caused by same threads calling themselves (e.g. VIEW_OK ack msgs)
> - Preemption doesn't work: Scheduler is meaningless here

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:42:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3844) "array element type
 mismatch"
 when deserializing JAX-RPC value type properties of array type when size >2
In-Reply-To: <18484945.1163176662202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32549154.1187692939093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3844?page=all ]

Thomas Diesler resolved JBAS-3844.
----------------------------------

    Resolution: Out of Date

Does this still occur with jbossws-2.0.1.GA?

> "array element type mismatch" when deserializing JAX-RPC value type properties of array type when size >2  
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3844
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3844
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Andrei Iltchenko
>         Assigned To: Thomas Diesler
>
> We experience a problem with the WS4EE stack on JBoss 4.0.3 when deserializing JAX-RPC value type properties of array type when the number of elements is greater than 2 and when the request envelope was created by a .NET client. There are similar issues reported on AXIS. Here's a typical stack trace we get:
> 14:59:13,330 ERROR [BeanPropertyTarget] Could not convert [Lcrm.application.business.common.customersvc.CallDataObject; to bean field 'typedElements[2]', type [Lcrm.application.business.common.customersvc.CallDataObject;
> 14:59:13,390 ERROR [RPCInvocation] java.lang.IllegalArgumentException: array element type mismatch
> java.lang.IllegalArgumentException: array element type mismatch
>       at org.jboss.axis.encoding.ser.BeanPropertyTarget.set(BeanPropertyTarget.java:243)
>       at org.jboss.axis.encoding.DeserializerImpl.valueComplete(DeserializerImpl.java:305)
>       at org.jboss.axis.encoding.DeserializerImpl.endElement(DeserializerImpl.java:590)
>       at org.jboss.axis.encoding.DeserializationContextImpl.endElement(DeserializationContextImpl.java:1269)
>       at org.jboss.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:252)
>       at org.jboss.axis.message.SOAPElementAxisImpl.publishToHandler(SOAPElementAxisImpl.java:1394)
>       at org.jboss.axis.message.RPCElement.deserialize(RPCElement.java:266)
>       at org.jboss.axis.message.RPCElement.getParams(RPCElement.java:402)
>       at org.jboss.axis.providers.java.RPCInvocation.prepareFromRequestEnvelope(RPCInvocation.java:235)
>       at org.jboss.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:103)
>       at org.jboss.axis.providers.java.JavaProvider.invoke(JavaProvider.java:358)
>       at org.jboss.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:73)
>       at org.jboss.axis.SimpleChain.doVisiting(SimpleChain.java:160)
>       at org.jboss.axis.SimpleChain.invoke(SimpleChain.java:123)
>       at org.jboss.axis.handlers.soap.SOAPService.invoke(SOAPService.java:560)
>       at org.jboss.webservice.server.ServerEngine.invokeInternal(ServerEngine.java:215)
>       at org.jboss.webservice.server.ServerEngine.invoke(ServerEngine.java:104)
>       at org.jboss.axis.transport.http.AxisServlet.doPost(AxisServlet.java:911)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>       at org.jboss.axis.transport.http.AxisServletBase.service(AxisServletBase.java:370)
>       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:524)
>       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)
>  
>  
> Message:
>  
>       <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
>         <soap:Header>
>           <wsa:Action>
>           </wsa:Action>
>           <wsa:MessageID>urn:uuid:6bdec88b-6594-4cae-81a5-628b86b75699</wsa:MessageID>
>           <wsa:ReplyTo>
>             <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
>           </wsa:ReplyTo>
>           <wsa:To>http://localhost:8082/ws/customersvc</wsa:To>
>           <wsse:Security>
>             <wsu:Timestamp wsu:Id="Timestamp-b935bb5d-4a72-4b8d-ba5d-d529e18cc23e">
>               <wsu:Created>2006-11-10T13:59:13Z</wsu:Created>
>               <wsu:Expires>2006-11-10T14:04:13Z</wsu:Expires>
>             </wsu:Timestamp>
>           </wsse:Security>
>         </soap:Header>
>         <soap:Body>
>           <setCustomerDo xmlns="http://logic.business.application.crm">
>             <update xmlns="">
>               <deleted>false</deleted>
>               <created>true</created>
>               <pruned>true</pruned>
>               <Original xsi:nil="true" />
>               <CRC>0</CRC>
>               <customerId>0002</customerId>
>               <contractDate>2006-11-07T00:00:00</contractDate>
>               <call>
>                 <typedElements>
>                   <deleted>false</deleted>
>                   <created>true</created>
>                   <pruned>true</pruned>
>                   <Original xsi:nil="true" />
>                   <CRC>0</CRC>
>                   <callResolved>false</callResolved>
>                   <callDescription xsi:nil="true" />
>                   <callTimestamp>0001-01-01T00:00:00</callTimestamp>
>                 </typedElements>
>                 <typedElements>
>                   <deleted>false</deleted>
>                   <created>true</created>
>                   <pruned>true</pruned>
>                   <Original xsi:nil="true" />
>                   <CRC>0</CRC>
>                   <callResolved>false</callResolved>
>                   <callDescription xsi:nil="true" />
>                   <callTimestamp>0001-01-01T00:00:00</callTimestamp>
>                 </typedElements>
>                 <typedElements>
>                   <deleted>false</deleted>
>                   <created>true</created>
>                   <pruned>true</pruned>
>                   <Original xsi:nil="true" />
>                   <CRC>0</CRC>
>                   <callResolved>false</callResolved>
>                   <callDescription xsi:nil="true" />
>                   <callTimestamp>0001-01-01T00:00:00</callTimestamp>
>                 </typedElements>
>               </call>
>               <firstName>Andre</firstName>
>               <serviceAgreement>
>                 <deleted>false</deleted>
>                 <created>true</created>
>                 <pruned>true</pruned>
>                 <Original xsi:nil="true" />
>                 <CRC>0</CRC>
>                 <serviceLevel>
>                   <value>1</value>
>                 </serviceLevel>
>                 <saDescription>Medium Service</saDescription>
>                 <saPrice>50.95</saPrice>
>                 <customer />
>                 <saId>0001</saId>
>               </serviceAgreement>
>               <customerTitle>Mr</customerTitle>
>               <lastName>Bos</lastName>
>               <address>
>                 <countryCode>31</countryCode>
>                 <phone xsi:nil="true" />
>                 <zipCode>1005 BB</zipCode>
>                 <street>Hoogoorddreef</street>
>                 <city>Amsterdam</city>
>                 <stateCode xsi:nil="true" />
>                 <email>Reinier.Bos at nl.compuware.com</email>
>               </address>
>             </update>
>           </setCustomerDo>
>         </soap:Body>
>       </soap:Envelope>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:44:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:44:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3960) Web Service Test
 case failed in JBoss AS 4.0.5GA
In-Reply-To: <19740846.1166771331635.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18801902.1187693059605.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3960?page=all ]

Thomas Diesler resolved JBAS-3960.
----------------------------------

    Resolution: Out of Date

Fixed with jboss-4.2.1

> Web Service Test case failed in JBoss AS 4.0.5GA
> ------------------------------------------------
>
>                 Key: JBAS-3960
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3960
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Arch: x86_64
> OS:   RHEL4U4
> JVM: Sun jdk version "1.5.0_06"
> JBoss Version: JBoss AS 4.0.5 GA and JBoss AS 4.0.5 GA src 
>            Reporter: Steven lian
>         Assigned To: Thomas Diesler
>
> When running JBoss AS testsuite,the testcase org.jboss.test.webservice.secure.SimpleClientSecureTestCase and  org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase is failed for the exceptions.
> reproduce steps:
> 1.build jboss AS 4.0.5 src and start JBoss server with all configuration
> 2.cd $JBOSS_HOME_SRC/testsuite
> 3.ant onte-test -Dtest=org.jboss.test.webservice.secure.SimpleClientSecureTestCase
> 4.ant onte-test -Dtest=org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase
> Result:
> Buildfile: build.xml
> one-test:
>    [delete] Deleting: /root/jboss-4.0.5.GA-src/testsuite/output/log/test.log
>     [junit] Running org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 3.502 sec
>     [junit] Test org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase FAILED
> one-test:
>    [delete] Deleting: /root/jboss-4.0.5.GA-src/testsuite/output/log/test.log
>     [junit] Running org.jboss.test.webservice.secure.SimpleClientSecureTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 3.934 sec
>     [junit] Test org.jboss.test.webservice.secure.SimpleClientSecureTestCase FAILED
> The test log :
> Testcase: testWithTransportOptions took 1.934 sec
>         Caused an 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(Unknown Source)
>         at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:90)
>         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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:47:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16234348.1187693239019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4567?page=all ]

Thomas Diesler updated JBAS-4567:
---------------------------------

    Summary: Install jbossws-2.0.1.GA  (was: Install jbossws-2.1.0.GA)

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:47:19 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10971432.1187693239524.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4567?page=all ]

Thomas Diesler resolved JBAS-4567.
----------------------------------

    Resolution: Done

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 06:47:20 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3671)
 org.jboss.axis.ConfigurationException: No engine configuration file
In-Reply-To: <13187415.1158701761524.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20273960.1187693240138.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3671?page=all ]

Thomas Diesler resolved JBAS-3671.
----------------------------------

    Resolution: Out of Date

Fixed with jbossws in jboss-4.2.x

> 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 lists.jboss.org  Tue Aug 21 06:47:20 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:47:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3670)
 org.jboss.axis.ConfigurationException: No engine configuration file
In-Reply-To: <7732126.1158701761366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30517272.1187693240368.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3670?page=all ]

Thomas Diesler resolved JBAS-3670.
----------------------------------

    Resolution: Duplicate Issue

> 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 lists.jboss.org  Tue Aug 21 06:49:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 06:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3827) Remove JMS
	transport support
In-Reply-To: <8347223.1162772081450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32260339.1187693358282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3827?page=all ]

Thomas Diesler resolved JBAS-3827.
----------------------------------

    Fix Version/s:     (was: JBossAS-4.2.2.GA)
       Resolution: Out of Date

> Remove JMS transport support
> ----------------------------
>
>                 Key: JBAS-3827
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3827
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>
> This should all be handled by jbossws

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 07:13:31 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 07:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
In-Reply-To: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7473986.1187694811692.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-578?page=all ]

Bela Ban resolved JGRP-578.
---------------------------

    Resolution: Rejected

Connect() and disconnect() or close() are not supposed to be called from different threads, so the above issue is a bit artificial.
I don't want to move the lock down (e.g. around leaving) as this increases the finite state space and therefore complicates the code.
I intend to remove the disable_initial_coord in 3.0 anyway, so this issue is moot.
Since there is a workaround for cancellation of connect(), your code should continue running fine.

> It is possible to create a deadlock when trying to close a channel which is not yet connected
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-578
>                 URL: http://jira.jboss.com/jira/browse/JGRP-578
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1_5_0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.
> Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Tue Aug 21 07:21:20 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 07:21:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4092) Clean up the
 tests-webservice-ssl target
In-Reply-To: <24737466.1171313430026.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33524187.1187695280179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4092?page=all ]

Thomas Diesler resolved JBAS-4092.
----------------------------------

    Resolution: Done

Fixed in trunk and Branch_4_4

> Clean up the tests-webservice-ssl target
> ----------------------------------------
>
>                 Key: JBAS-4092
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4092
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>            Priority: Minor
>             Fix For: JBossAS-4.2.2.GA
>
>
> There is a server.xml file for the tests-webservice-ssl target. However, no tests actually get executed when you run this target. According to build.xml in testsuite, here are the tests it is trying to pull in: 
> <patternset id="webservice-ssl.includes"> 
>     <include name="org/jboss/test/webservice/secure/**/*TestCase.class"/> 
>     <exclude name="org/jboss/test/webservice/secure/noenv/**/*TestCase.class"/> 
>   </patternset> 
> So I guess the tests-webservice-ssl target is obsolete? Can someone from the Web Services team comment?
> (see JBAS-4025)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 07:24:27 2007
From: jira-events at lists.jboss.org (Alexandre Russel (JIRA))
Date: Tue, 21 Aug 2007 07:24:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-11) Memory based
	eviction policy
Message-ID: <5185146.1187695467183.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-11?page=all ]

Alexandre Russel updated JBCACHE-11:
------------------------------------

    Attachment: memoryBaseEviction.txt

Hi,
a patch not meant to be comited but to get things started.
the idea is to separate:
when is there eviction => decided by EvictionTask.
which node is evicted => decided by the algorithm.
how many are evicted => decided by the number of nodes in the cache.

The patch keep the algoritm. It creates an abstract class EvictionTask,
with 2 child EvictionTimerTask (the previous EvictionTask) and 
EvictionMemoryTask (a new EvictionTask based on memory).

I added setter and getter on EvictionPolicyConfig for maxNodes.

The EvictionMemoryTask listen to the memory pool that support usage threshold
and that matches a regexp given in config.
It accept 2 settings, a minimum and a maximum percentage of memory.
When there is a notification that the first minimum of memory is
exceded, the maximum number of nodes is set to half its value.
If it goes over the maximum percentage the maximum number of nodes goes to 1.

I used sun's jvm. If you run the test, you may want to check the number
 of objects put in the list. It was set to be a raisonable value on my
computer.

If you think it is a good way to add memory based eviction, let me know
and I'll improve on it. (Few improvements would be to be able to increment 
max nodes when memory is back to a low value and have more than just 2 values 
max and min)
alex


> Memory based eviction policy
> ----------------------------
>
>                 Key: JBCACHE-11
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-11
>             Project: JBoss Cache
>          Issue Type: Feature Request
>          Components: Eviction
>            Reporter: Bela Ban
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>         Attachments: memoryBaseEviction.txt
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> (maybe only in JDK 1.5, which has
>   triggers for low memory)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 07:41:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 07:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-577) AUTH: join
 rejection won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15436589.1187696478380.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-577?page=comments#action_12373105 ] 
            
Bela Ban commented on JGRP-577:
-------------------------------

This was caused by UNICAST which created a Connection for B on the first (failed) JOIN. Subsequent JOINs failed because that connection was not removed on the failed JOIN, so A incorrectly used the old connection.
Fixed in CVS head (2.6) and 2.5.1

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>         Attachments: a.log, b.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Tue Aug 21 07:55:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 07:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-577) AUTH: join rejection
 won't be received because UNICAST drops it
In-Reply-To: <30975370.1187247961107.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12953272.1187697318238.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-577?page=all ]

Bela Ban resolved JGRP-577.
---------------------------

    Resolution: Done

done as suggested in comment, tested in CVS head and 2.5 branch

> AUTH: join rejection won't be received because UNICAST drops it
> ---------------------------------------------------------------
>
>                 Key: JGRP-577
>                 URL: http://jira.jboss.com/jira/browse/JGRP-577
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>         Attachments: a.log, b.log
>
>
> When AUTH processes a JOIN request and rejects it, it sends back a unicast message to the joiner. However, that message is dropped by UNICAST as the destination is not in the membership !
> SOLUTION: use Event.ENABLE_UNICASTS_TO before sending the rejection. (This works in TCP as there is no UNICASR protocol in 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 lists.jboss.org  Tue Aug 21 08:44:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 21 Aug 2007 08:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3450) Fix
 org.jboss.test.webservice.jbws309.JBWS309TestCase running under JACC
In-Reply-To: <7324549.1154372651507.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30223221.1187700258563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3450?page=all ]

Thomas Diesler reassigned JBAS-3450:
------------------------------------

    Assignee: Anil Saldhana  (was: Thomas Diesler)

How can I reproduce this?

> Fix org.jboss.test.webservice.jbws309.JBWS309TestCase running under JACC
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3450
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3450
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Security
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> EJBContext.isCallerInRole checks now goes through the JACC layer. (http://jira.jboss.com/jira/browse/JBAS-2661)
> So there may be changes needed in the ejb-jar.xml wrt security role-refs

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:11:44 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Tue, 21 Aug 2007 09:11:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1043) ProcessDefinition
 delete throws
 HibernateException: null index column for collection: org.
 jbpm.graph.def.ProcessDefinition.actions
Message-ID: <1819964.1187701904099.JavaMail.jira@cloud.prod.atl2.jboss.com>

ProcessDefinition delete throws HibernateException: null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 
------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPM-1043
                 URL: http://jira.jboss.com/jira/browse/JBPM-1043
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
            Reporter: Martin Putz
         Assigned To: Tom Baeyens


if the process definition contains a task with notify="yes", eg.

	<task-node name="mail">
		<task name="email info" notify="yes">
			<assignment actor-id="mputz"></assignment>
		</task>
		<transition to="end-state1"></transition>
	</task-node>

the deletion of this process definition results in the stated HibernateException:
null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:16:18 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Tue, 21 Aug 2007 09:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1043) ProcessDefinition
 delete throws
 HibernateException: null index column for collection: org.
 jbpm.graph.def.ProcessDefinition.actions
In-Reply-To: <1819964.1187701904099.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30665904.1187702178458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1043?page=all ]

Martin Putz updated JBPM-1043:
------------------------------

    Attachment: JBPM-1043.patch.txt

attached patch for JpdlXmlReader - the Action object was not set up properly on notify="yes" marked tasks

> ProcessDefinition delete throws HibernateException: null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1043
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1043
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: Martin Putz
>         Assigned To: Tom Baeyens
>         Attachments: JBPM-1043.patch.txt
>
>
> if the process definition contains a task with notify="yes", eg.
> 	<task-node name="mail">
> 		<task name="email info" notify="yes">
> 			<assignment actor-id="mputz"></assignment>
> 		</task>
> 		<transition to="end-state1"></transition>
> 	</task-node>
> the deletion of this process definition results in the stated HibernateException:
> null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:47:32 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:47:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
Message-ID: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add EJB2.x JMX metrics to EJB3
------------------------------

                 Key: EJBTHREE-1033
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC9 - Patch 1
            Reporter: Carlo de Wolf
         Assigned To: William DeCoste
             Fix For: AS 4.2.0 GA


Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount

Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize

MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:47:32 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:47:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4681014.1187704052722.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1033?page=all ]

Carlo de Wolf updated EJBTHREE-1033:
------------------------------------

    Fix Version/s: EJB 3.0 RC11 - FD
                       (was: AS 4.2.0 GA)
         Assignee: Carlo de Wolf  (was: William DeCoste)

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:49:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14692018.1187704158425.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1033?page=comments#action_12373130 ] 
            
Carlo de Wolf commented on EJBTHREE-1033:
-----------------------------------------

The counterpart of EJBTHREE-825 for trunk

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:56:02 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 21 Aug 2007 09:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15779980.1187704562822.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1033?page=comments#action_12373145 ] 
            
Carlo de Wolf commented on EJBTHREE-1033:
-----------------------------------------

TODO: mdb

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 09:59:18 2007
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Tue, 21 Aug 2007 09:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1107) Support for
 multiple pattern in accumulate source pattern
Message-ID: <12689020.1187704758710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support for multiple pattern in accumulate source pattern
---------------------------------------------------------

                 Key: JBRULES-1107
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1107
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions:  4.0.0.GA
            Reporter: Juergen none
         Assigned To: Mark Proctor


Accumulate should support more than one pattern as source pattern. e.g.:

Number() from accumulate(
    Cheese(
        price : price,
        type : type
    )
    Person(
        favouriteCheese == type,
        age > 30
    ),
    sum( price )
)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:17:29 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 10:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1057) Create/update
 DTD/schemas for descriptors.
In-Reply-To: <11332006.1158952801489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32556261.1187705849631.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1057?page=all ]

Chris Laprun resolved JBPORTAL-1057.
------------------------------------

    Resolution: Partially Completed

This is done for WSRP and I don't know what the status of the other DTDs is, nor if it's important at this point. Resolving for now, will re-open if there's a strong client need.

> 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 Reference Guide
>    Affects Versions: 2.6.Alpha1
>            Reporter: Chris Laprun
>            Priority: Minor
>             Fix For: 2.4.3 Final
>
>         Attachments: jboss-portlet.dtd, jboss-wsrp.dtd, portlet-instances.dtd, portlet-object.dtd
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:19:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 10:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1141) use binaries
 under jbossas instead of portal while running portal testsuite
In-Reply-To: <16762511.1164666295798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <147849.1187705958233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1141?page=all ]

Chris Laprun resolved JBPORTAL-1141.
------------------------------------

    Resolution: Won't Fix

It's been determined that the efforts involved to solve this issue are not worth the time: without a profile notion, this would be rather complicated to set up as there are some dependences on thirdparty as well.

> use binaries under jbossas instead of portal while running portal testsuite
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1141
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1141
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal QA
>    Affects Versions: 2.4 Final
>            Reporter: Prabhat Jha
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.4.3 Final
>
>
> WSRP tests had failed while testing portal2.4.1.CR1 with jboss4.0.5 because there was a mismatch in webservices binary versions. To remove this conflict, it would be better if portal testsuite could point to jbossas binaries instead of binaries under portal/thirdparty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:21:22 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Tue, 21 Aug 2007 10:21:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1042)
 org.jbpm.JbpmException: token
 '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
In-Reply-To: <14744899.1187285881464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <765933.1187706082450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1042?page=comments#action_12373162 ] 
            
Ronald van Kuijk commented on JBPM-1042:
----------------------------------------

so close this issue and reopen a new one? or discuss this 'recursion' on the dev list.

> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1042
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: jBPM 3.2.1
> Java 1.6 update 2
> Windows XP
> Run as a standalone Java application. No app server.
> Use the standard test framework and configuration. (HyperSonic, etc).  Same behavior with Oracle 10g
>            Reporter: Jeff Johnson
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>         Attachments: jbpm-jpdl.jar, SimpleAsyncProcessTest.java
>
>
> org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]' is thrown  when a node has an ActionHandler that propagates execution via  ExecutionContext.leaveNode() to a node that is marked as async="true".
> My ActionHandler.execute() method: 
>     public void execute(ExecutionContext executionContext) throws Exception
>     {
>       // Normally would do stuff here
>       // Leave via the default transition
>       // When this test case was written, this method would throw when 
>       // it tried to enter Node2 because it would try to lock the token but 
>       // it is already locked.
>       executionContext.leaveNode();
>     }
>   }
> Section 9.5 of the user guide states: "Note the difference
> between an action that is placed in an event versus an action that is placed in a node. Actions that are put in an event
> are executed when the event fires. Actions on events have no way to influence the flow of control of the process.
> It is similar to the observer pattern. On the other hand, an action that is put on a node has the responsibility of propagating the execution.
> The execute() method from Node does not propagate the execution context if there is a custom action associated with the node. Based on this code and the documentation above, I concluded that I must propagate the execution inside my action handler.
> // From org.jbpm.graph.def.Node.execute()
> public void execute(ExecutionContext executionContext) {
>     // if there is a custom action associated with this node
>     if (action!=null) {
>       try {
>         // execute the action
>         executeAction(action, executionContext);
>       } catch (Exception exception) {
>         // NOTE that Error's are not caught because that might halt the JVM and mask the original Error.
>         // search for an exception handler or throw to the client
>         raiseException(exception, executionContext);
>       }
>     } else {
>       // let this node handle the token
>       // the default behaviour is to leave the node over the default transition.
>       leave(executionContext);
>     }
>   }
> However this appears to conflict with the comments for Token.lock()
>  /**
>    * locks a process instance for further execution.  A locked token 
>    * cannot continue execution.  This is a non-persistent
>    * operation.  This is used to prevent tokens being propagated during 
>    * the execution of actions.
>    * @see #unlock(String) 
>    */
>   public void lock(String lockOwnerId) {
> Originally this test case failed in jBPM 3.2.1 with the following exception
>  * org.jbpm.JbpmException: token '1' can't be locked by 'job[1]' cause it's already locked by 'token[1]'
>   at org.jbpm.graph.exe.Token.lock(Token.java:646)
>   at org.jbpm.graph.def.Node.enter(Node.java:316)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.def.Node.leave(Node.java:357)
>   at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest$AsyncAction.execute(SimpleAsyncProcessTest.java:57)
>   at org.jbpm.graph.def.Action.execute(Action.java:122)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$4852cc95.execute(<generated>)
>   at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:255)
>   at org.jbpm.graph.def.Node.execute(Node.java:338)
>   at org.jbpm.graph.def.Node.enter(Node.java:318)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.enter(<generated>)
>   at org.jbpm.graph.def.Transition.take(Transition.java:151)
>   at org.jbpm.graph.def.Node.leave(Node.java:393)
>   at org.jbpm.graph.node.StartState.leave(StartState.java:70)
>   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 org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:157)
>   at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cc789161.leave(<generated>)
>   at org.jbpm.graph.exe.Token.signal(Token.java:194)
>   at org.jbpm.graph.exe.Token.signal(Token.java:139)
>   at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:270)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.launchProcess(SimpleAsyncProcessTest.java:112)
>   at org.jbpm.job.executor.SimpleAsyncProcessTest.testConsecutiveAycnActionHandlers(SimpleAsyncProcessTest.java:69)
>   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.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 10:53:29 2007
From: jira-events at lists.jboss.org (Anders Persson (JIRA))
Date: Tue, 21 Aug 2007 10:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-580) Possible to get the
 channel into an incorrect and/or inconsistent state
Message-ID: <13608722.1187708009162.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible to get the channel into an incorrect and/or inconsistent state
-----------------------------------------------------------------------

                 Key: JGRP-580
                 URL: http://jira.jboss.com/jira/browse/JGRP-580
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.5
         Environment: Windows XP; java 1.5.0_12
            Reporter: Anders Persson
         Assigned To: Bela Ban


The channel is trying to establish a connection. While trying to create the connection there is a Event.EXIT traversed up the stack. This will close the channel and at the same time release connect(). The problem is that when the thread returns to connect() it will continue as if the connect is continuing successfully. This will result in a channel which is set to be connected even though it is actually closed. This will also cause the auto reconnect to fail since the channel considers itself to be connected.

After this long description I think that the following snippet of code will provide a better description.

Today in JChannel the code looks like this:
    public synchronized void connect(String cluster_name) throws ChannelException {
...stuff going on...
            Event connect_event = new Event(Event.CONNECT, cluster_name);
            Object res = downcall(connect_event); // waits forever until
            // connected (or channel is
            // closed)
                if (res != null && res instanceof Exception) { // the JOIN was
                    // rejected by the
                    // coordinator
                    throw new ChannelException("connect() failed", (Throwable) res);
                }

This should be changed to:

            Event connect_event = new Event(Event.CONNECT, cluster_name);
            Object res = downcall(connect_event); // waits forever until
            // connected (or channel is
            // closed)

            /*
             * This is an added section to this method. The if statement will
             * check if the downcall method returned as a result of an
             * Event.EXIT. If so then we should consider this channel to be NOT
             * connected. Otherwise connected will be set to true and any
             * further calls to connect will fail (also auto reconnect will fail
             * for this reason).
             */
            if (!closed) {
                if (res != null && res instanceof Exception) { // the JOIN was
                    // rejected by the
                    // coordinator
                    throw new ChannelException("connect() failed", (Throwable) res);
                }

It obviously has to be verified that the closed flag is set before calling any stop methods on the protocols.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 11:06:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-399) Create retro
 builds for javaee project
Message-ID: <6688898.1187708778359.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create retro builds for javaee project
--------------------------------------

                 Key: JBBUILD-399
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-399
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Create jdk14 retro builds for the javaee subproject of 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 lists.jboss.org  Tue Aug 21 11:08:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-399) Create retro
 builds for javaee project
In-Reply-To: <6688898.1187708778359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20642756.1187708898319.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-399?page=all ]

Paul Gier reassigned JBBUILD-399:
---------------------------------

    Assignee: Paul Gier

> Create retro builds for javaee project
> --------------------------------------
>
>                 Key: JBBUILD-399
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-399
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>
> Create jdk14 retro builds for the javaee subproject of 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 lists.jboss.org  Tue Aug 21 11:34:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-400) Create retro
 builds for AS integration project
Message-ID: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create retro builds for AS integration project
----------------------------------------------

                 Key: JBBUILD-400
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
    Affects Versions: Maven Build - App Server
            Reporter: Paul Gier


Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 11:34:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 11:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-400) Create retro
 builds for AS integration project
In-Reply-To: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15774241.1187710458549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-400?page=all ]

Paul Gier reassigned JBBUILD-400:
---------------------------------

    Assignee: Paul Gier

> Create retro builds for AS integration project
> ----------------------------------------------
>
>                 Key: JBBUILD-400
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>    Affects Versions: Maven Build - App Server
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 11:34:19 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Tue, 21 Aug 2007 11:34:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8196133.1187710459100.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=all ]

Manik Surtani updated JBCACHE-1166:
-----------------------------------

    Fix Version/s: 2.1.0.GA

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Tue Aug 21 11:38:18 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Tue, 21 Aug 2007 11:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1165) Endless loop in
 PessimisticLockInterceptor
In-Reply-To: <14669904.1187336057521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10290441.1187710698292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1165?page=all ]

Manik Surtani updated JBCACHE-1165:
-----------------------------------

    Fix Version/s: 1.4.1.SP5

> Endless loop in PessimisticLockInterceptor
> ------------------------------------------
>
>                 Key: JBCACHE-1165
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.SP5
>
>         Attachments: ConcurentPutRemoveTest.java, ConsoleOut.log
>
>
> When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop.
> Main loop looks like:
> 				for (int x = 0; x < 1000; x++) {
> 					tm.begin();
> 					System.out.println("R" + Thread.currentThread().getName());
> 					//inside transaction
> 					cache.remove("/a");
> 					System.out.println("AR" + Thread.currentThread().getName());
> 					tm.commit();
> 					//outside transaction
> 					System.out.println("P" + Thread.currentThread().getName());
> 					cache.put("/a/b/c/d", "text"+x,"b");
> 					System.out.println("AP" + Thread.currentThread().getName());
> 				}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 11:46:32 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 21 Aug 2007 11:46:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-629) Unneccessary
 puts in message store
In-Reply-To: <10858183.1162379381434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10835610.1187711192649.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-629?page=all ]

Tim Fox updated JBMESSAGING-629:
--------------------------------

    Fix Version/s: 1.4.0.CR2
                       (was: 2.0.0 Beta 1)

> Unneccessary puts in message store
> ----------------------------------
>
>                 Key: JBMESSAGING-629
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-629
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.GA, 1.2.0.Alpha1
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> We are currently executing unnecessary puts into the message store on the primary execution path of message routing.
> When a new message arrives - it is first added to the message store. The message is only ever retrieved from the message store if a reference is loaded from paging and we want to make sure we do not have more than once instance in memory at once.
> The first put is therefore unnecessary and will have some performance implications. Also message store is currently a synchronization bottleneck so this should aid concurrency. Messages should only be added to the message store (if necessary) when they are paged to storage

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 11:46:32 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 21 Aug 2007 11:46:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-629) Unneccessary
 puts in message store
In-Reply-To: <10858183.1162379381434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27791890.1187711192775.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-629?page=all ]

Tim Fox closed JBMESSAGING-629.
-------------------------------

    Resolution: Done

> Unneccessary puts in message store
> ----------------------------------
>
>                 Key: JBMESSAGING-629
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-629
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.GA, 1.2.0.Alpha1
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> We are currently executing unnecessary puts into the message store on the primary execution path of message routing.
> When a new message arrives - it is first added to the message store. The message is only ever retrieved from the message store if a reference is loaded from paging and we want to make sure we do not have more than once instance in memory at once.
> The first put is therefore unnecessary and will have some performance implications. Also message store is currently a synchronization bottleneck so this should aid concurrency. Messages should only be added to the message store (if necessary) when they are paged to storage

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:10:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Tue, 21 Aug 2007 13:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1167) Heuristic outcome
 (STATUS_UNKNOWN) of transaction not handled properly
Message-ID: <9760798.1187716218788.JavaMail.jira@cloud.prod.atl2.jboss.com>

Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
----------------------------------------------------------------------

                 Key: JBCACHE-1167
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1167
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.1.SP4, 2.0.0.GA
            Reporter: Galder Zamarreno
         Assigned To: Manik Surtani
             Fix For: 1.4.1.SP5


Where an XA transaction has a heuristic outcome, the status reported to 
the afterCompletion synchronization is STATUS_UNKNOWN (5), since 
JTA does not handle heuristics. In this case, the cache Synchronization 
fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked) 
state even though the XA transaction has been resolved. 

At first glance it looks like the afterCompletion synchronization should treat a 
STATUS_UNKNOWN as a cause for rollback as well as logging the error as 
they currently do. Unfortunately the fix may be more complex than that, since 
the db may have committed rather than rolled back, meaning the cache would 
be out of sync with the db if you rolled it 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 lists.jboss.org  Tue Aug 21 13:10:19 2007
From: jira-events at lists.jboss.org (Elias Ross (JIRA))
Date: Tue, 21 Aug 2007 13:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4618) Thread context
 classloader not set during transaction commit
Message-ID: <26613768.1187716219333.JavaMail.jira@cloud.prod.atl2.jboss.com>

Thread context classloader not set during transaction commit
------------------------------------------------------------

                 Key: JBAS-4618
                 URL: http://jira.jboss.com/jira/browse/JBAS-4618
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Elias Ross


I modified a serializable object, part of an EJB3 Entity, during an MDB.onMessage() call. Hibernate attempts to update this serializable object during the transaction commit, but fails because it cannot load the class from the classloader. For example, if one modifies an entity such as:

@Entity
public class Foo {
  Serializable bar;
...
}

in an MDB

public class MDB implements MessageListener {
  @PersistenceContext
  EntityManager em;
  public void onMessage() {
    Foo f = em.load(...);
    f.setBar(new ScopedClass());
  }
}

you get this error.

The thread context classloader is assigned when processing the message. Is it cleared after message processing or after transaction completion? From my limited understanding of the code, it seems like the former. There appears to be an invoker that sets and clears during processing, but the clear apparently happens before transaction commit.

Ordinarily, transaction commit does not require the context classloader of the .ear file, but in this case it 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 lists.jboss.org  Tue Aug 21 13:10:21 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:10:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1639) Let the
 administrator enable or disable a user
In-Reply-To: <17294032.1187352901536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18216425.1187716221925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1639?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1639.
-------------------------------------------

    Resolution: Done

the admin can now enable/disable users in the user management

> Let the administrator enable or disable a user 
> -----------------------------------------------
>
>                 Key: JBPORTAL-1639
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1639
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:12:18 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1638) Modify "edit
 profile" to let modification of email and password
In-Reply-To: <8183870.1187352782096.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14962956.1187716338710.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1638?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1638.
-------------------------------------------

    Resolution: Done

admin can change the email address and reset the password of a user. 

> Modify "edit profile" to let modification of email and password 
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-1638
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1638
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:12:18 2007
From: jira-events at lists.jboss.org (Elias Ross (JIRA))
Date: Tue, 21 Aug 2007 13:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4618) Thread context
 classloader not set during transaction commit
In-Reply-To: <26613768.1187716219333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31728611.1187716338942.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4618?page=comments#action_12373196 ] 
            
Elias Ross commented on JBAS-4618:
----------------------------------

This is with JBoss 4.2.0.

And by "this error", I mean this exception

2007-07-25 11:14:41,313 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.type.SerializationException: could not deserialize
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:214)
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:240)
at org.hibernate.type.SerializableType.fromBytes(SerializableType.java:82)
at org.hibernate.type.SerializableType.deepCopyNotNull(SerializableType.java:74)
at org.hibernate.type.MutableType.deepCopy(MutableType.java:25)
at org.hibernate.type.SerializableToBlobType.deepCopy(SerializableToBlobType.java:102)
at org.hibernate.type.TypeFactory.deepCopy(TypeFactory.java:353)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:114)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:249)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1256)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:494)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:248)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: com.example.msg.ScopedClass
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:514)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:408)
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:574)
at org.hibernate.util.SerializationHelper$CustomObjectInputStream.resolveClass(SerializationHelper.java:268)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538)
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.readObject(ObjectInputStream.java:339)
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:210)
... 28 more	


> Thread context classloader not set during transaction commit
> ------------------------------------------------------------
>
>                 Key: JBAS-4618
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4618
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Elias Ross
>
> I modified a serializable object, part of an EJB3 Entity, during an MDB.onMessage() call. Hibernate attempts to update this serializable object during the transaction commit, but fails because it cannot load the class from the classloader. For example, if one modifies an entity such as:
> @Entity
> public class Foo {
>   Serializable bar;
> ...
> }
> in an MDB
> public class MDB implements MessageListener {
>   @PersistenceContext
>   EntityManager em;
>   public void onMessage() {
>     Foo f = em.load(...);
>     f.setBar(new ScopedClass());
>   }
> }
> you get this error.
> The thread context classloader is assigned when processing the message. Is it cleared after message processing or after transaction completion? From my limited understanding of the code, it seems like the former. There appears to be an invoker that sets and clears during processing, but the clear apparently happens before transaction commit.
> Ordinarily, transaction commit does not require the context classloader of the .ear file, but in this case it 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 lists.jboss.org  Tue Aug 21 13:12:19 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:12:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1636) Captcha support
 (with jcpatcha probably)
In-Reply-To: <32032096.1187352781527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11808504.1187716339100.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1636?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1636.
-------------------------------------------

    Resolution: Done

added captcha (jcaptcha) for registering and for requesting a new password

> Captcha support (with jcpatcha probably) 
> -----------------------------------------
>
>                 Key: JBPORTAL-1636
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1636
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:14:18 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 21 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1635) Lost password
 feature, attribute a random password and send it by email
In-Reply-To: <26661164.1187352668657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5035347.1187716458642.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1635?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1635.
-------------------------------------------

    Resolution: Done

The user can now request a new password by using his username.

> Lost password feature, attribute a random password and send it by email 
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1635
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1635
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Tue Aug 21 13:14:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1641) Portal link (top
 right of page) in admin results in 403 error
Message-ID: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portal link (top right of page) in admin results in 403 error
-------------------------------------------------------------

                 Key: JBPORTAL-1641
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.8 Final
            Reporter: Chris Laprun
             Fix For: 2.8 Final


Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:18:19 2007
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Tue, 21 Aug 2007 13:18:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1051) Failure of
 one JMS Server may cause VIEW to not propogate in JBM cluster
Message-ID: <4493142.1187716699014.JavaMail.jira@cloud.prod.atl2.jboss.com>

Failure of one JMS Server may cause VIEW to not propogate in JBM cluster
------------------------------------------------------------------------

                 Key: JBMESSAGING-1051
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1051
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.0.CR1
         Environment:  JBoss 4.2.1 EAP with JBM 1.4 HEAD running on two CentOS5  servers with a shared MySQL 5.x db.
            Reporter: Ray Ploski
         Assigned To: Tim Fox


In a two-node JBM cluster, after one of the nodes is hard-killed (kill -9), the server cannot be restarted.  

An "IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id ([MY_SERVER_NODE]). Are you sure you have given each node a unique node id during installation?" occurs semi-frequently in a two-node JBM cluster.  

While looking at the surviving node, you can see all members of the view (both the dead and alive) in the PostOffice.NodeIDView.


A restart of all members of the cluster is required to resolve the issue.  

 ERROR [org.jboss.messaging.util.ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService at 456a5c7c startService
java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (172). Are you sure you have given each node a unique node id during installation?
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:335)
        at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:413)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
        at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
        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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:417)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        at org.jboss.system.ServiceController.start(ServiceController.java:435)
        ..


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:26:18 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Tue, 21 Aug 2007 13:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1167) Heuristic outcome
 (STATUS_UNKNOWN) of transaction not handled properly
In-Reply-To: <9760798.1187716218788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8588727.1187717178646.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1167?page=all ]

Manik Surtani updated JBCACHE-1167:
-----------------------------------

    JBoss Forum Reference: http://lists.jboss.org/pipermail/jbosscache-dev/2007-August/001968.html

> Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-1167
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1167
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.4.1.SP4
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.SP5
>
>
> Where an XA transaction has a heuristic outcome, the status reported to 
> the afterCompletion synchronization is STATUS_UNKNOWN (5), since 
> JTA does not handle heuristics. In this case, the cache Synchronization 
> fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked) 
> state even though the XA transaction has been resolved. 
> At first glance it looks like the afterCompletion synchronization should treat a 
> STATUS_UNKNOWN as a cause for rollback as well as logging the error as 
> they currently do. Unfortunately the fix may be more complex than that, since 
> the db may have committed rather than rolled back, meaning the cache would 
> be out of sync with the db if you rolled it 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 lists.jboss.org  Tue Aug 21 13:35:18 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 21 Aug 2007 13:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
Message-ID: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add parseRoleNameFromDN option to LdapExtLoginModule
----------------------------------------------------

                 Key: JBAS-4619
                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Mike Millson
         Assigned To: Scott M Stark


Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 

The option would look something like:

<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleNameAttributeID">myprofile</module-option>
<module-option name="parseRoleNameFromDN">true</module-option>

Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:41:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 21 Aug 2007 13:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-795) Allow bisocket
 server to run behind a NAT router
Message-ID: <767687.1187718078471.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow bisocket server to run behind a NAT router
------------------------------------------------

                 Key: JBREM-795
                 URL: http://jira.jboss.com/jira/browse/JBREM-795
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.2.0.SP4_CP02
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.2.GA, 2.2.0.SP4_CP02


When org.jboss.remoting.transport.bisocket.BisocketServerInvoker received a request to return the address of the secondary ServerSocket, it returns ServerSocket.getInetAddress().getHostAddress(), which may not be accessible to the outside world.  

The secondary ServerSocket should be configurable just like the primary ServerSocket, which has parameters "serverBindAddress", "serverBindPort", "clientConnectAddress", and "clientConnectPort".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 13:43:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 21 Aug 2007 13:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBREM-795) Allow bisocket
 server to run behind a NAT router
Message-ID: <30339254.1187718198377.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-795?page=all ]

Ron Sigal deleted JBREM-795:
----------------------------


> Allow bisocket server to run behind a NAT router
> ------------------------------------------------
>
>                 Key: JBREM-795
>                 URL: http://jira.jboss.com/jira/browse/JBREM-795
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>
> When org.jboss.remoting.transport.bisocket.BisocketServerInvoker received a request to return the address of the secondary ServerSocket, it returns ServerSocket.getInetAddress().getHostAddress(), which may not be accessible to the outside world.  
> The secondary ServerSocket should be configurable just like the primary ServerSocket, which has parameters "serverBindAddress", "serverBindPort", "clientConnectAddress", and "clientConnectPort".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 14:16:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1642) Usability
	improvements
Message-ID: <14088977.1187720178310.JavaMail.jira@cloud.prod.atl2.jboss.com>

Usability improvements
----------------------

                 Key: JBPORTAL-1642
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1642
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core, Portal Core Admin, Portal WSRP
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.2 Final


Umbrella task for work on usability.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 14:18:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1643) Replace
 "Destroy" by "Delete" where applicable
Message-ID: <14683022.1187720298181.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace "Destroy" by "Delete" where applicable
----------------------------------------------

                 Key: JBPORTAL-1643
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1643
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
            Priority: Minor
             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 21 14:55:30 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:55:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1644) Add Default
 status / Make Default action to object (e.g. portal, page) tables
Message-ID: <4492260.1187722530673.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add Default status / Make Default action to object (e.g. portal, page) tables
-----------------------------------------------------------------------------

                 Key: JBPORTAL-1644
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1644
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 21 14:57:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 14:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1642) Usability
	improvements
In-Reply-To: <14088977.1187720178310.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6730692.1187722638217.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1642?page=all ]

Chris Laprun updated JBPORTAL-1642:
-----------------------------------

    Fix Version/s: 2.8 Final

> Usability improvements
> ----------------------
>
>                 Key: JBPORTAL-1642
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1642
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal WSRP, Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> Umbrella task for work on usability.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 15:12:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 15:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1643) Replace
 "Destroy" by "Delete" where applicable
In-Reply-To: <14683022.1187720298181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9124972.1187723538210.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1643?page=all ]

Chris Laprun updated JBPORTAL-1643:
-----------------------------------

    Fix Version/s: 2.8 Final

> Replace "Destroy" by "Delete" where applicable
> ----------------------------------------------
>
>                 Key: JBPORTAL-1643
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1643
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 21 15:12:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 15:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1643) Replace
 "Destroy" by "Delete" where applicable
In-Reply-To: <14683022.1187720298181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30435674.1187723538306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1643?page=all ]

Chris Laprun resolved JBPORTAL-1643.
------------------------------------

    Resolution: Done

> Replace "Destroy" by "Delete" where applicable
> ----------------------------------------------
>
>                 Key: JBPORTAL-1643
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1643
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 21 16:20:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-401) Add support for
 retro-translating javax.xml.namespace.QName
Message-ID: <20808895.1187727618234.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for retro-translating javax.xml.namespace.QName
-----------------------------------------------------------

                 Key: JBBUILD-401
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-401
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
            Reporter: Paul Gier
             Fix For: JBossRetro-1.1.3.GA


The microcontainer kernel module uses javax.xml.namespace.QName which is a jdk1.5 class.  Support should be added to jboss-retro to retro weave 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 lists.jboss.org  Tue Aug 21 16:26:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 16:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1645) Don't show
 properties table if there are no properties
Message-ID: <9644068.1187727978328.JavaMail.jira@cloud.prod.atl2.jboss.com>

Don't show properties table if there are no properties
------------------------------------------------------

                 Key: JBPORTAL-1645
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1645
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 21 16:30:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-402) Add support for
 jdk1.5 Big Decimal methods
Message-ID: <6024074.1187728218240.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for jdk1.5 Big Decimal methods
------------------------------------------

                 Key: JBBUILD-402
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-402
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: JBossRetro
    Affects Versions: JBossRetro-1.1.2.GA
            Reporter: Paul Gier


The class java.math.BigDecimal added several new methods in jdk1.5.  Support for these should be added to the retro weaving.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:30:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-402) Add support for
 jdk1.5 Big Decimal methods
In-Reply-To: <6024074.1187728218240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4373611.1187728218362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-402?page=all ]

Paul Gier updated JBBUILD-402:
------------------------------

    Fix Version/s: JBossRetro-1.1.3.GA

> Add support for jdk1.5 Big Decimal methods
> ------------------------------------------
>
>                 Key: JBBUILD-402
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-402
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: JBossRetro
>    Affects Versions: JBossRetro-1.1.2.GA
>            Reporter: Paul Gier
>             Fix For: JBossRetro-1.1.3.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> The class java.math.BigDecimal added several new methods in jdk1.5.  Support for these should be added to the retro weaving.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:33:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
Message-ID: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add config parameter to specify groupId in jboss deploy plugin
--------------------------------------------------------------

                 Key: JBBUILD-403
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: maven-jboss-deploy-plugin
    Affects Versions: maven-jboss-deploy-plugin-1.3
            Reporter: Paul Gier


Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:37:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
In-Reply-To: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5629046.1187728638456.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-403?page=all ]

Paul Gier updated JBBUILD-403:
------------------------------

    Fix Version/s: maven-jboss-deploy-plugin-1.4

> Add config parameter to specify groupId in jboss deploy plugin
> --------------------------------------------------------------
>
>                 Key: JBBUILD-403
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-deploy-plugin
>    Affects Versions: maven-jboss-deploy-plugin-1.3
>            Reporter: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:37:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-404) Create project
 site for jboss-deploy plugin.
Message-ID: <27716106.1187728638760.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create project site for jboss-deploy plugin.
--------------------------------------------

                 Key: JBBUILD-404
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-404
             Project: JBoss Build System
          Issue Type: Task
          Components: maven-jboss-deploy-plugin
            Reporter: Paul Gier
             Fix For: maven-jboss-deploy-plugin-1.4


There should be a project site that contains documentation for the plugin on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:43:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 16:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1645) Don't show
 properties table if there are no properties
In-Reply-To: <9644068.1187727978328.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <79384.1187728998852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1645?page=all ]

Chris Laprun resolved JBPORTAL-1645.
------------------------------------

       Resolution: Done
    Fix Version/s: 2.8 Final
                   2.6.2 Final

> Don't show properties table if there are no properties
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1645
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1645
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 21 16:45:48 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 16:45:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1645) Don't show
 properties table if there are no properties
In-Reply-To: <9644068.1187727978328.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32983307.1187729148787.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1645?page=all ]

Chris Laprun updated JBPORTAL-1645:
-----------------------------------

    Affects Version/s: 2.6.1 Final
          Component/s: Portal Core Admin

> Don't show properties table if there are no properties
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1645
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1645
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Tue Aug 21 16:49:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-405) Research issue with
 microcontainer kernel retro builds
Message-ID: <13171755.1187729358453.JavaMail.jira@cloud.prod.atl2.jboss.com>

Research issue with microcontainer kernel retro builds
------------------------------------------------------

                 Key: JBBUILD-405
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-405
             Project: JBoss Build System
          Issue Type: Task
          Components: JBossRetro, Maven
            Reporter: Paul Gier
             Fix For: Maven Build - Maint 2007


The microcontainer kernel is not able to compile with dependency on retroed version of jboss-container.  It compiles ok depending on the regular container, but with the retro container, there is a problem with the annotations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 16:55:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:55:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-406) Create retro build
	for aop
Message-ID: <1127269.1187729719337.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create retro build for aop
--------------------------

                 Key: JBBUILD-406
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-406
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


AOP needs a retro 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 lists.jboss.org  Tue Aug 21 16:57:29 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-399) Create retro builds
 for javaee project
In-Reply-To: <6688898.1187708778359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17090031.1187729849179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-399?page=all ]

Paul Gier closed JBBUILD-399.
-----------------------------

    Resolution: Done

Poms for retro build have been added.

> Create retro builds for javaee project
> --------------------------------------
>
>                 Key: JBBUILD-399
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-399
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>
> Create jdk14 retro builds for the javaee subproject of 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 lists.jboss.org  Tue Aug 21 16:59:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-400) Create retro
 builds for AS integration project
In-Reply-To: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32532554.1187729958438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-400?page=all ]

Paul Gier updated JBBUILD-400:
------------------------------

    Affects Version/s:     (was: Maven Build - App Server)
        Fix Version/s: Maven Build - App Server

> Create retro builds for AS integration project
> ----------------------------------------------
>
>                 Key: JBBUILD-400
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 16:59:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-400) Create retro builds
 for AS integration project
In-Reply-To: <30252238.1187710458434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29788361.1187729958662.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-400?page=all ]

Paul Gier closed JBBUILD-400.
-----------------------------

    Resolution: Done

Poms for a retro build of the integration project have been added.

> Create retro builds for AS integration project
> ----------------------------------------------
>
>                 Key: JBBUILD-400
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-400
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Create retro jdk14 builds for the AS integration 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 lists.jboss.org  Tue Aug 21 17:07:32 2007
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 21 Aug 2007 17:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1034) Port
 ejb3/src/main/org/jboss/ejb3/enc/DeploymentPersistenceUnitResolver.java to
 Branch_4_2
Message-ID: <22376933.1187730452121.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port ejb3/src/main/org/jboss/ejb3/enc/DeploymentPersistenceUnitResolver.java to Branch_4_2
------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1034
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1034
             Project: EJB 3.0
          Issue Type: Patch
    Affects Versions: AS 4.2.2.GA
            Reporter: Frank Langelage
             Fix For: AS 4.2.2.GA


Port the changes made on ejb3/src/main/org/jboss/ejb3/enc/DeploymentPersistenceUnitResolver.java in Head to Branch 4.2.
Using an ear with seperated session and entity beans (different ejb-modules) I got the exception "There is no default persistence nit in this deployment." when using "@PersistenceContext private EntityManager entityManager;" in my Session Bean.
Using the head version of the source file within my 4.2.2.GA cvs checkout the problem went away.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 17:07:32 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 21 Aug 2007 17:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1644) Add Default
 status / Make Default action to object (e.g. portal, page) tables
In-Reply-To: <4492260.1187722530673.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1130647.1187730452212.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1644?page=all ]

Chris Laprun updated JBPORTAL-1644:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final

> Add Default status / Make Default action to object (e.g. portal, page) tables
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1644
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1644
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Tue Aug 21 17:29:53 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 21 Aug 2007 17:29:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-93) Add
 JBossRetro builds for Microcontainer projects
Message-ID: <7690033.1187731793352.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=comments#action_12373237 ] 
            
Paul Gier commented on JBMICROCONT-93:
--------------------------------------

As I'm creating and testing the retro poms, I've found several missing features in JBoss retro that will need to be implemented to get all the tests working.  I've created jira issues under the jboss retro project for the missing features.

> Add JBossRetro builds for Microcontainer projects
> -------------------------------------------------
>
>                 Key: JBMICROCONT-93
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93
>             Project: JBoss MicroContainer
>          Issue Type: Sub-task
>          Components: General
>            Reporter: Adrian Brock
>         Assigned To: Paul Gier
>             Fix For: JBossMC-2.0.0.CR1
>
>
> Make JBossRetro builds for the microcontainer projects
> such that they can use JDK5 features.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 18:54:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Aug 2007 18:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-580) Possible to get the
 channel into an incorrect and/or inconsistent state
In-Reply-To: <13608722.1187708009162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19557420.1187736858887.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-580?page=all ]

Bela Ban updated JGRP-580:
--------------------------

    Fix Version/s: 2.6

> Possible to get the channel into an incorrect and/or inconsistent state
> -----------------------------------------------------------------------
>
>                 Key: JGRP-580
>                 URL: http://jira.jboss.com/jira/browse/JGRP-580
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1.5.0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The channel is trying to establish a connection. While trying to create the connection there is a Event.EXIT traversed up the stack. This will close the channel and at the same time release connect(). The problem is that when the thread returns to connect() it will continue as if the connect is continuing successfully. This will result in a channel which is set to be connected even though it is actually closed. This will also cause the auto reconnect to fail since the channel considers itself to be connected.
> After this long description I think that the following snippet of code will provide a better description.
> Today in JChannel the code looks like this:
>     public synchronized void connect(String cluster_name) throws ChannelException {
> ...stuff going on...
>             Event connect_event = new Event(Event.CONNECT, cluster_name);
>             Object res = downcall(connect_event); // waits forever until
>             // connected (or channel is
>             // closed)
>                 if (res != null && res instanceof Exception) { // the JOIN was
>                     // rejected by the
>                     // coordinator
>                     throw new ChannelException("connect() failed", (Throwable) res);
>                 }
> This should be changed to:
>             Event connect_event = new Event(Event.CONNECT, cluster_name);
>             Object res = downcall(connect_event); // waits forever until
>             // connected (or channel is
>             // closed)
>             /*
>              * This is an added section to this method. The if statement will
>              * check if the downcall method returned as a result of an
>              * Event.EXIT. If so then we should consider this channel to be NOT
>              * connected. Otherwise connected will be set to true and any
>              * further calls to connect will fail (also auto reconnect will fail
>              * for this reason).
>              */
>             if (!closed) {
>                 if (res != null && res instanceof Exception) { // the JOIN was
>                     // rejected by the
>                     // coordinator
>                     throw new ChannelException("connect() failed", (Throwable) res);
>                 }
> It obviously has to be verified that the closed flag is set before calling any stop methods on the protocols.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 21:11:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 21:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1086) InitialFact
 should not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33482974.1187745078337.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1086?page=all ]

Michael Neale reassigned JBRULES-1086:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 21:53:34 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 21:53:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1028) importing
 .brxml into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31984118.1187747614475.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=comments#action_12373246 ] 
            
Michael Neale commented on JBRULES-1028:
----------------------------------------

For some more details on how to do this: 

BRXMLPersistence.getInstance().unmarshal -- this gives a RuleModel from the XML
BRDRLPersistence.getinstance.marshal - this takes the RuleModel and dumps out the DRL
The name in the RuleModel SHOULD be the same as the file that it came from. If its not, it would be best to set it to the same as the file (minus the extension).

The DRL can then be added to the PackageBuilder - of course this will also need the imports added beforehand etc (and the package name). 

In the BRMS this is all done with ContentpackageAssembler. In the IDE, the Guided editor will create some .package file that contains the imports etc... thats how the editor knows what to work with. 

This code will need to cater for that. So we can either make people use package builder plus the above, OR we can enhance package builder, OR we create an ant task to automate it all.

If we have an ant task, it needs to cater for ALL asset types (like the BRMS does) - that includes decision tables, .dslr rules (loading up the dsl files) and ruleflows, adding it all to a package. Thus the ant task can be pointed at a folder and it will do the rest (of course it needs a classpath).



> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Tue Aug 21 21:55:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 21:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23129056.1187747718340.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1083?page=all ]

Michael Neale reassigned JBRULES-1083:
--------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 22:00:18 2007
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Tue, 21 Aug 2007 22:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1051) Failure of
 one JMS Server may cause VIEW to not propogate in JBM cluster
In-Reply-To: <4493142.1187716699014.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31842317.1187748018409.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1051?page=comments#action_12373247 ] 
            
Ray Ploski commented on JBMESSAGING-1051:
-----------------------------------------

Found that this issue is related to using an unsupported MySQL engine - the clustering ndb engine.  This is related to mysql bug: http://bugs.mysql.com/bug.php?id=9144. Catching the exception and re-invoking the executeQuery is enough to make this work.

The error listed below comes from the surviving node of the cluster:

2007-08-21 11:43:01,779 2097431 ERROR [org.jgroups.protocols.UDP] @IncomingPacketHandler (channel=MessagingPostOffice) failed unmarshalling message
java.lang.IllegalStateException: General error message from server: "Got error 241 'Invalid schema object version' from ndbcluster"
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2001)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1168)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1279)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:2281)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1634)
        at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:236)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.mergeAndLoad(JDBCPersistenceManager.java:933)
        at org.jboss.messaging.core.impl.MessagingQueue.mergeIn(MessagingQueue.java:217)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.performFailover(MessagingPostOffice.java:2924)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:901)
        at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:469)
        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:735)
        at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
        at org.jgroups.JChannel.up(JChannel.java:1091)
        at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
        at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:487)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
        at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:568)
        at org.jgroups.protocols.pbcast.GMS.up(GMS.java:707)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
        at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:520)

> Failure of one JMS Server may cause VIEW to not propogate in JBM cluster
> ------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1051
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1051
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.CR1
>         Environment:  JBoss 4.2.1 EAP with JBM 1.4 HEAD running on two CentOS5  servers with a shared MySQL 5.x db.
>            Reporter: Ray Ploski
>         Assigned To: Tim Fox
>
> In a two-node JBM cluster, after one of the nodes is hard-killed (kill -9), the server cannot be restarted.  
> An "IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id ([MY_SERVER_NODE]). Are you sure you have given each node a unique node id during installation?" occurs semi-frequently in a two-node JBM cluster.  
> While looking at the surviving node, you can see all members of the view (both the dead and alive) in the PostOffice.NodeIDView.
> A restart of all members of the cluster is required to resolve the issue.  
>  ERROR [org.jboss.messaging.util.ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService at 456a5c7c startService
> java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (172). Are you sure you have given each node a unique node id during installation?
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:335)
>         at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:413)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
>         at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
>         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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:417)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         at org.jboss.system.ServiceController.start(ServiceController.java:435)
>         ..

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 22:10:18 2007
From: jira-events at lists.jboss.org (Luke Maurer (JIRA))
Date: Tue, 21 Aug 2007 22:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1108) Eclipse DRL
 editor unusable on dark background
Message-ID: <28516158.1187748618463.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eclipse DRL editor unusable on dark background
----------------------------------------------

                 Key: JBRULES-1108
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1108
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
         Environment: Eclipse 3.3.0
            Reporter: Luke Maurer
         Assigned To: Mark Proctor


Having a dark background color for editors in Eclipse makes the default DRL syntax highlighting unusable (as is the case with most Eclipse editors). Unfortunately, the editor's syntax highlighting can be neither changed nor disabled, so the DRL editor is completely unusable for me. While fully customizable syntax highlighting would be the best, simply being able to disable it entirely (and use Eclipse's default text color, which I of course have set to white) would be a perfectly good workaround.

I set the background color to black in Preferences -> General -> Editors -> Text Editors -> Background color, and the foreground color to white on the same page.

(Of course, this is really Eclipse's fault for forcing every single editor to have its very own ad-hoc syntax highlighting configuration system ... but I'd better not get started :-) )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 22:45:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 22:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1086) InitialFact should
 not be shadowed
In-Reply-To: <9627680.1187205430653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9879638.1187750718294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1086?page=all ]

Michael Neale closed JBRULES-1086.
----------------------------------

    Resolution: Done

> InitialFact should not be shadowed
> ----------------------------------
>
>                 Key: JBRULES-1086
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1086
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Anh Vuong
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> If the app uses its own classLoader,  Exception IllegalAccessError will be thrown when inserting fact. Here is the stack trace:
> 2007 Aug 15, 09:08:13:193        Exception IllegalAccessError
> java.lang.IllegalAccessError: class org.drools.reteoo.InitialFactImplShadowProxy cannot access its superclass org.drools.reteoo.Init 
> ialFactImpl
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
>         at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
>         at java.lang.ClassLoader.loadClass (Unknown Source)
>         at org.drools.reteoo.Rete$ObjectTypeConf.loadOrGenerateProxy(Rete.java:379)
>         at org.drools.reteoo.Rete$ObjectTypeConf.defineShadowProxyData(Rete.java:344)
>         at org.drools.reteoo.Rete$ObjectTypeConf .<init>(Rete.java:320)
>         at org.drools.reteoo.Rete.assertObject(Rete.java:145)
>         at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
>         at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
>         at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
>         at org.drools.common.AbstractWorkingMemory.insert (AbstractWorkingMemory.java:623)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 21 23:51:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 21 Aug 2007 23:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1083) Brackets are not
 always optional for non-existential quantifier "not"
In-Reply-To: <28853926.1187125566425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8547307.1187754678298.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1083?page=all ]

Michael Neale closed JBRULES-1083.
----------------------------------

    Resolution: Done

Documentation updated (including railroad) to reflect this. The brackets can only ever be optional for a single pattern.

> Brackets are not always optional for non-existential quantifier "not" 
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1083
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1083
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Markus Reitz
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> According to the documentation, brackets are optional as illustrated by
>   Example 6.37. No Busses
>   not Bus()
> In case of the rule (class SpecialString in http://jira.jboss.com/jira/browse/JBRULES-1079)
>   package test
>   rule "Brackets"
>     when
>       not exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe")))
>     then
>       System.out.println("Condition satisfied");
>   end
> this is not true. Trying to load this rule leads to
> org.drools.rule.InvalidRulePackage: [8,8]: unknown:8:8 Unexpected token 'exists'
> at org.drools.rule.Package.checkValidity(Package.java:408)
> at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> at DroolsTest.<init>(Unknown Source)
> at DroolsTest.main(Unknown Source)
> When brackets are added:
>   package test
>   rule "Brackets"
>     when
>       not(exists(x : SpecialString() and
>                  forall(y : SpecialString(this!=x)
>                             SpecialString(this==y, text=="Universe"))))
>     then
>       System.out.println("Condition satisfied");
>   end
> rule loading works without any exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 00:19:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 00:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27333004.1187756358292.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373252 ] 
            
Michael Neale commented on JBRULES-1065:
----------------------------------------

This isn't a bug per se - this was not implemented this way.

You can do:

$record : Record( abc == $record.xyz )

I can't see how abc = xyz would work - it would be very very ambiguous for non trivial usage. We could do a:

this.xyz - how does that sound? 

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 02:13:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 02:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18552399.1187763198294.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373258 ] 
            
Michael Neale commented on JBRULES-1065:
----------------------------------------

ok there are 2 ways (this isn't a bug technically): 

You can do $record : Record( abc == $record.xyz)

is that close enough? 

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 04:14:18 2007
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 22 Aug 2007 04:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBADMCON-151) The web-console
 tree does not
 appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so
 plugin
Message-ID: <31546280.1187770458348.JavaMail.jira@cloud.prod.atl2.jboss.com>

The web-console tree does not appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so plugin
----------------------------------------------------------------------------------------------------------------

                 Key: JBADMCON-151
                 URL: http://jira.jboss.com/jira/browse/JBADMCON-151
             Project: JBoss Admin Console
          Issue Type: Bug
         Environment: Server Side
Version
Version: 4.0.5GA(build: CVSTag=Branch_4_0 date=200610162340)
Version Name: Zion
Built on: October 16 2006 

Environment
Start date: Wed Aug 22 09:13:47 CEST 2007
Host: Oops
Base Location: file:/jboss/jboss-portal-2.6/server/
Base Location (local): /jboss/jboss-portal-2.6/server
Running config: 'default

Hardware
#CPU: 1
OS: Linux 2.6.20-2925.9.fc7xen (i386)

JVM Environment
Free Memory: 49 MB
Max Memory: 506 MB
Total Memory: 126 MB
#Threads: 42
JVM Version: 1.6.0-b105 (Sun Microsystems Inc.)
JVM Name: Java HotSpot(TM) Server VM

Client Side
Hardware
#CPU: 1
OS: Linux 2.6.20-2925.9.fc7xen (i386)
Software
firefox 2.0.0.5

JVM Env
Sun JRE jre1.6.0_02

            Reporter: Frederic Hornain
            Priority: Minor


Hi,

Well, I have set the Java plugin on firefox as described below but I did not managed to see the web-console applets.
it is always a blank page on the left frame and the JBoss? Application Server information on the right frame.

ln -s  /usr/java/latest/plugin/i386/ns7/libjavaplugin_oji.so /home/user/.mozilla/plugins/libjavaplugin_oji.so 

Thanks in advance for your help.

BR
Fred

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Aug 22 04:20:18 2007
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 22 Aug 2007 04:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBADMCON-151) The web-console
 tree does not
 appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so
 plugin
In-Reply-To: <31546280.1187770458348.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32745621.1187770818231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-151?page=all ]

Frederic Hornain updated JBADMCON-151:
--------------------------------------


Hi,

it is me again.
Well, I do not think this problem is linked to Jboss cause I had the same issue with the applets demo from sun - http://java.sun.com/applets/jdk/1.4/index.html -.

Nothing happens.

Keep you in touch if I found how to fix this issue.

BR 
Fred


> The web-console tree does not appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so plugin
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBADMCON-151
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-151
>             Project: JBoss Admin Console
>          Issue Type: Bug
>         Environment: Server Side
> Version
> Version: 4.0.5GA(build: CVSTag=Branch_4_0 date=200610162340)
> Version Name: Zion
> Built on: October 16 2006 
> Environment
> Start date: Wed Aug 22 09:13:47 CEST 2007
> Host: Oops
> Base Location: file:/jboss/jboss-portal-2.6/server/
> Base Location (local): /jboss/jboss-portal-2.6/server
> Running config: 'default
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> JVM Environment
> Free Memory: 49 MB
> Max Memory: 506 MB
> Total Memory: 126 MB
> #Threads: 42
> JVM Version: 1.6.0-b105 (Sun Microsystems Inc.)
> JVM Name: Java HotSpot(TM) Server VM
> Client Side
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> Software
> firefox 2.0.0.5
> JVM Env
> Sun JRE jre1.6.0_02
>            Reporter: Frederic Hornain
>            Priority: Minor
>
> Hi,
> Well, I have set the Java plugin on firefox as described below but I did not managed to see the web-console applets.
> it is always a blank page on the left frame and the JBoss? Application Server information on the right frame.
> ln -s  /usr/java/latest/plugin/i386/ns7/libjavaplugin_oji.so /home/user/.mozilla/plugins/libjavaplugin_oji.so 
> Thanks in advance for your help.
> BR
> Fred

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:38:20 2007
From: jira-events at lists.jboss.org (Wolfgang Hollweck (JIRA))
Date: Wed, 22 Aug 2007 04:38:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1044)
 TaskMgmtInstance.removeSignalling(Token token) - Remove signalling
 capabilities from all task instances related to the given token
Message-ID: <11857253.1187771900133.JavaMail.jira@cloud.prod.atl2.jboss.com>

TaskMgmtInstance.removeSignalling(Token token) - Remove signalling capabilities from all task instances related to the given token
----------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPM-1044
                 URL: http://jira.jboss.com/jira/browse/JBPM-1044
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions: jBPM jPDL 3.2, jBPM 3.1.4
            Reporter: Wolfgang Hollweck
         Assigned To: Tom Baeyens


There is a bug in TaskMgmtinstance.removeSignalling(Token token) of jBPM versions 3.1.4 and 3.2:

Signalling is set to false for all TaskInstances that are in the current TaskMgmtInstance.
It has to be checked, that signalling is removed only from TaskInstances belonging to the given Token.
(see forum)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:40:31 2007
From: jira-events at lists.jboss.org (Wolfgang Hollweck (JIRA))
Date: Wed, 22 Aug 2007 04:40:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1044)
 TaskMgmtInstance.removeSignalling(Token token) - Remove signalling
 capabilities from all task instances related to the given token
In-Reply-To: <11857253.1187771900133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21528751.1187772031853.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1044?page=all ]

Wolfgang Hollweck updated JBPM-1044:
------------------------------------

    Fix Version/s: jBPM jPDL 3.2.2
                   jBPM 4.0
                   jBPM jPDL 3.2 beta 2
                   jBPM 3.1.4

> TaskMgmtInstance.removeSignalling(Token token) - Remove signalling capabilities from all task instances related to the given token
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1044
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1044
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2, jBPM 3.1.4
>            Reporter: Wolfgang Hollweck
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 4.0, jBPM 3.1.4, jBPM jPDL 3.2 beta 2, jBPM jPDL 3.2.2
>
>
> There is a bug in TaskMgmtinstance.removeSignalling(Token token) of jBPM versions 3.1.4 and 3.2:
> Signalling is set to false for all TaskInstances that are in the current TaskMgmtInstance.
> It has to be checked, that signalling is removed only from TaskInstances belonging to the given Token.
> (see forum)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:43:19 2007
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Wed, 22 Aug 2007 04:43:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30325493.1187772199049.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-89?page=all ]

Jean-Frederic Clere reassigned JBWEB-89:
----------------------------------------

    Assignee: Jean-Frederic Clere  (was: Mladen Turk)

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Jean-Frederic Clere
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 04:47:18 2007
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 22 Aug 2007 04:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBADMCON-151) The web-console
 tree does not
 appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so
 plugin
In-Reply-To: <31546280.1187770458348.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5944976.1187772438418.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-151?page=all ]

Frederic Hornain resolved JBADMCON-151.
---------------------------------------

    Resolution: Done

Hi again,

Finally I found why how to fix it;
Sorry to have disturbing you.

So this is the solution :

1 Open a terminal .

2 Login as root by entering the following.
su - 

3 At the password prompt enter the password for root. 
Install the compatiablility libraries by performing the following:
yum -y install compat-libstdc++-33 compat-libstdc++-296

or search these files on the Fedora Extra repository on the web, download them and install them with the rpm command:
rpm -ivh  install compat-libstdc++-33.rpm compat-libstdc++-296.rpm

4 After the libraries are installed perform the following:
/sbin/ldconfig

Ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib). The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their linksupdated.

Oh yes do not forget to create the symbolic link described above in the problem describtion.

Finally do not forget as well to export the JAVA_HOME and the new PATH environment which could be usefull if you would like to develop in java in your terminal. But i am pretty sure you already know that.

Have fun  with JBOSS
And feel free to contact me if you need more details about this problem.

BR
Fred


> The web-console tree does not appear at all on firefox 2.0.0.5 using JRE jre1.6.0_02 libjavaplugin_oji.so plugin
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBADMCON-151
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-151
>             Project: JBoss Admin Console
>          Issue Type: Bug
>         Environment: Server Side
> Version
> Version: 4.0.5GA(build: CVSTag=Branch_4_0 date=200610162340)
> Version Name: Zion
> Built on: October 16 2006 
> Environment
> Start date: Wed Aug 22 09:13:47 CEST 2007
> Host: Oops
> Base Location: file:/jboss/jboss-portal-2.6/server/
> Base Location (local): /jboss/jboss-portal-2.6/server
> Running config: 'default
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> JVM Environment
> Free Memory: 49 MB
> Max Memory: 506 MB
> Total Memory: 126 MB
> #Threads: 42
> JVM Version: 1.6.0-b105 (Sun Microsystems Inc.)
> JVM Name: Java HotSpot(TM) Server VM
> Client Side
> Hardware
> #CPU: 1
> OS: Linux 2.6.20-2925.9.fc7xen (i386)
> Software
> firefox 2.0.0.5
> JVM Env
> Sun JRE jre1.6.0_02
>            Reporter: Frederic Hornain
>            Priority: Minor
>
> Hi,
> Well, I have set the Java plugin on firefox as described below but I did not managed to see the web-console applets.
> it is always a blank page on the left frame and the JBoss? Application Server information on the right frame.
> ln -s  /usr/java/latest/plugin/i386/ns7/libjavaplugin_oji.so /home/user/.mozilla/plugins/libjavaplugin_oji.so 
> Thanks in advance for your help.
> BR
> Fred

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 06:07:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Aug 2007 06:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-581) Convert ReplicatedMap
 to ConcurrentHashMap from HashMap
Message-ID: <10186974.1187777238359.JavaMail.jira@cloud.prod.atl2.jboss.com>

Convert ReplicatedMap to ConcurrentHashMap from HashMap
-------------------------------------------------------

                 Key: JGRP-581
                 URL: http://jira.jboss.com/jira/browse/JGRP-581
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix 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 lists.jboss.org  Wed Aug 22 07:00:18 2007
From: jira-events at lists.jboss.org (Shahad Ahmed (JIRA))
Date: Wed, 22 Aug 2007 07:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1109) Exported BRMS
 repositories lose version history
Message-ID: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exported BRMS repositories lose version history
-----------------------------------------------

                 Key: JBRULES-1109
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
         Environment: Windows XP SP2, SUN JRE 1.5_09
            Reporter: Shahad Ahmed
         Assigned To: Mark Proctor


I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.

If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?

Here's how to replicate the problem for a clean BRMS install:

1. Create a new category called test.

2. In the defaultPackage create a new technical rule called test as shown below:

when
    eval(true)
then
    System.out.println("Hello");

3. Save the test rule

4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.

5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.

6. From Admin/Manage Backups save the repository.

7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).

8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 07:24:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Aug 2007 07:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-581) Convert
 ReplicatedMap to ConcurrentHashMap from HashMap
In-Reply-To: <10186974.1187777238359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24350364.1187781858195.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-581?page=all ]

Bela Ban resolved JGRP-581.
---------------------------

    Resolution: Done

> Convert ReplicatedMap to ConcurrentHashMap from HashMap
> -------------------------------------------------------
>
>                 Key: JGRP-581
>                 URL: http://jira.jboss.com/jira/browse/JGRP-581
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix 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 lists.jboss.org  Wed Aug 22 07:34:19 2007
From: jira-events at lists.jboss.org (Anders Persson (JIRA))
Date: Wed, 22 Aug 2007 07:34:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-578) It is possible to
 create a
 deadlock when trying to close a channel which is not yet connected
In-Reply-To: <29036815.1187632801851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25894897.1187782459496.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-578?page=all ]

Anders Persson reopened JGRP-578:
---------------------------------

             
Well, I would definitely not make JChannel depend on the leaving flag in GMS. In my view JChannel should be kept complety protocol neutral.

The solution I see is to introduce an abort method in Protocol. Calling this method would have the effect that the protocol (subclass to Protocol) ceases its current blocking activites, much like you have an "abort flag" that you every now and then check when you are running a thread. The contract would then be that a protocol is obliged to implement abort in case it has any blocking activities. In the case of GMS it would mean that abort() would do the same as stop(), that is, set the leaving flag to true.

The pseudo code in JChannel would be something like

public close()
protocolStack.abort()
synchronized(this)

In other words the synchronized block is only started once the abort has been called. You would keep the synchronized statement on the connect method as is. The synchronization ensures that connect() will finish its business before close() proceeds. I see this as a simple and clean approach to solve this issue. It is a generic way to implement the workaround already described.

> It is possible to create a deadlock when trying to close a channel which is not yet connected
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-578
>                 URL: http://jira.jboss.com/jira/browse/JGRP-578
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1_5_0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.
> Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 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 lists.jboss.org  Wed Aug 22 07:42:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 22 Aug 2007 07:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4620) NPE in EJB3
 Authentication Interceptor
Message-ID: <12500267.1187782938496.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE in EJB3 Authentication Interceptor
--------------------------------------

                 Key: JBAS-4620
                 URL: http://jira.jboss.com/jira/browse/JBAS-4620
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Thomas Diesler
         Assigned To: Anil Saldhana
             Fix For:  JBossAS-5.0.0.Beta3


Most EJB3 web service tests fail because of 

java.lang.NullPointerException
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:141)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
        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.wsf.container.jboss50.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:104)
        at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:220)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 07:44:18 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 22 Aug 2007 07:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4620) NPE in EJB3
 Authentication Interceptor
In-Reply-To: <12500267.1187782938496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6267908.1187783058505.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4620?page=comments#action_12373288 ] 
            
Thomas Diesler commented on JBAS-4620:
--------------------------------------

I already made  the jbossws container integration an integral part of the AS code base 

The issue is probably caused by invalid security code in org.jboss.wsf.container.jboss50.InvocationHandlerEJB3 which you will find in the newly created webservices module

To easily reproduce the issue, please follow 
http://jbws.dyndns.org/mediawiki/index.php?title=Building_From_Source#Checkout_and_build_JBossWS-Native

Hudson shows this regression here
http://jbws.dyndns.org:8280/hudson/job/Integration-Native-AS-5.0/

> NPE in EJB3 Authentication Interceptor
> --------------------------------------
>
>                 Key: JBAS-4620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Anil Saldhana
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Most EJB3 web service tests fail because of 
> java.lang.NullPointerException
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:141)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
>         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.wsf.container.jboss50.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:104)
>         at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:220)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 08:01:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 22 Aug 2007 08:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4620) NPE in EJB3
 Authentication Interceptor
In-Reply-To: <12500267.1187782938496.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31655768.1187784078305.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4620?page=all ]

Carlo de Wolf updated JBAS-4620:
--------------------------------

    Component/s: EJB3
       Priority: Blocker  (was: Major)

> NPE in EJB3 Authentication Interceptor
> --------------------------------------
>
>                 Key: JBAS-4620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Thomas Diesler
>         Assigned To: Anil Saldhana
>            Priority: Blocker
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Most EJB3 web service tests fail because of 
> java.lang.NullPointerException
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:141)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
>         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.wsf.container.jboss50.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:104)
>         at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:220)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 08:03:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11221606.1187784198294.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373293 ] 
            
Edson Tirelli commented on JBRULES-1065:
----------------------------------------

Michael,

What the user is asking for is auto-vivification for "variable restrictions". We already have that for return value restrictions and inline-evals. I think we should add this "syntax-sugar", since Tong is not the only user to request that.
But you are right, this is not a bug per se, and all following approaches already work:

$record : Record( abc == $record.xyz ) 
Record( abc == this.xyz )
Record( xyz : xyz, abc == xyz )

I will look into allowing that today.

Edson

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 08:39:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1065) Unable to
 return Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32356760.1187786358268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=comments#action_12373297 ] 
            
Edson Tirelli commented on JBRULES-1065:
----------------------------------------

Michael just told me that the following is not working, so I need to fix it.

Record( abc == this.xyz ) 

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 08:50:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1089) Getting "could
 not access property ('=')" for a valid rule.
In-Reply-To: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33163165.1187787018748.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1089?page=comments#action_12373298 ] 
            
Edson Tirelli commented on JBRULES-1089:
----------------------------------------

This problem is fixed in drools-compiler, but we still depend on mvel fixing:

http://jira.codehaus.org/browse/MVEL-29
http://jira.codehaus.org/browse/MVEL-30

As soon as it is done, I will close this ticket.


> Getting "could not access property ('=')" for a valid rule.
> -----------------------------------------------------------
>
>                 Key: JBRULES-1089
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
>            Reporter: Arsalan Zaidi
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
> Sent: 13 August 2007 22:16
> To: Rules Users List
> Subject: Re: [rules-users] could not access property ('=')
> Attachments: ATT426765.txt
>    This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?
>    Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 
> when
>            $dto : DTO( )
>            W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1
> then
>    Thanks, and hope it helps.
>    Edson
> 2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
>   Hi.
>   I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.
>   I have a rule which looks like this:
>   rule "W250.42 Editable"
>         when
>               DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )
>         then
>               System.out.println ("0" );
>               Action action = createAction("W250.42" , false , true );
>               retList.add(action); 
>   end 
>   both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .
>   Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.
>   org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )
>         at org.drools.reteoo.Rete.assertObject(Rete.java:168 )
>         at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 
>         at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )
>         at com.sample.DroolsTest.main( DroolsTest.java:34)
>   Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )
>         at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )
>         at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )
>         at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)
>         at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 
>         at org.mvel.MVEL.executeExpression( MVEL.java:202)
>         at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )
>         ... 10 more
>   Caused by: org.mvel.PropertyAccessException: could not access property ('=') 
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )
>         ... 18 more
>   If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.
>   I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')
>   What seems to be the issue?
>   Thanks in advance!
>   Regards,
>   --Arsalan
>         This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 
>        
>   _______________________________________________
>   rules-users mailing list
>   rules-users at lists.jboss.org 
>   https://lists.jboss.org/mailman/listinfo/rules-users
> -- 
>   Edson Tirelli
>   Software Engineer - JBoss Rules Core Developer
>   Office: +55 11 3529-6000
>   Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat @ www.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 lists.jboss.org  Wed Aug 22 08:52:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1047) class Cast
 Exception when using OR (||)
In-Reply-To: <20755281.1185814069735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22218134.1187787138411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1047?page=all ]

Edson Tirelli closed JBRULES-1047.
----------------------------------

    Resolution: Done

As I received no further info on this, I'm closing it. If the problem persists, please reopen it.


> class Cast Exception when using OR (||)
> ---------------------------------------
>
>                 Key: JBRULES-1047
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1047
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows, X86
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Trivial
>             Fix For: 4.0.1
>
>
> When I define a rule:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct, 
>                active:active==$1,
>                relationName=="Old")
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ..The bove works. 
> BUT, when I do the following:
> When
> cntct:Contact (initialized==true)
> exr:Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> || Relation( contact==cntct, 
>                active:active==$1,
>                relationName==null)
> Then
> contact.getStatus().setStatus(true);
> contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
> ... The script compiles anda stateless Session is created successfully, 
> but at 
> runtime/execution it fails with the exception:
> java.lang.ClassCastException: com.arjun.brms.businessObjects.Contact
> org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:75)
> org.drools.reteoo.EvalConditionNode.assertTuple (EvalConditionNode.java:141)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:120)
> org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple 
> (SingleTupleSinkAdapter.java:20)
> org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:317)
> org.drools.reteoo.AlphaNode.assertObject (AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:130)
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject 
> (CompositeObjectSinkAdapter.java:308)
> org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> org.drools.reteoo.Rete.assertObject(Rete.java:168)
> org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java :190)
> org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java :822)
> org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> Class diagram:
> ~~~~~~~~~~~~~~~~
> Contact<-- bi-directional association -->List<Relation>
> =============================================================================
> Edson comments (Response) :
> -----------------------------------------
> It is a bug since a more friendly message should be raised at compile time stating that your "contact" declaration is not available in one of your logical branches. 
>     Having said that, what you want to do is make your OR take priority over the implicit AND and as such, you need to add () around the OR: 
> When
> contact:Contact (initialized==true)
> exr: ( Relation( contact==cntct,
>                active:active==$1,
>                relationName=="Old")
> or Relation( contact==cntct,
>                active:active==$1, 
>                relationName==null) )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    Having said that, better yet for you would not to use the OR CE, but to use restriction connectives. This would be the most efficient (and clean) way of writing your rule: 
> When
> contact:Contact (initialized==true)
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName =="Old" || == null )
> Then
>     contact.getStatus().setStatus(true); 
>     contact.getStatus().addToReasonTrace(drools.getRule().getName());
> end
>    As a syntax sugar, you could also write:
> exr: Relation( contact==cntct,
>                active:active==$1,
>                relationName in ( "Old", null ) )
>    Can you please open a JIRA with your test case for the bug? 
>    Thank you,
>         Edson
> -------------------
> Note: The above suggestion worked, no runtime errors with 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 lists.jboss.org  Wed Aug 22 08:56:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 08:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1074) Support the use
 of Integer, Float, Short and Byte in accumulate functions
In-Reply-To: <14718682.1186924981314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1599861.1187787378509.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1074?page=all ]

Edson Tirelli updated JBRULES-1074:
-----------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

Expression type is currently managed by MVEL. We need to define a long term solution for this, so I'm moving this ticket to FUTURE.

> Support the use of Integer, Float, Short and Byte in accumulate functions
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1074
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1074
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: FUTURE
>
>
> Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 09:10:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 09:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1058) nested accessors
 with Sets - "not contains" is not a valid operator for MVEL
In-Reply-To: <28809761.1186253937246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8961340.1187788219023.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1058?page=all ]

Edson Tirelli closed JBRULES-1058.
----------------------------------

    Resolution: Duplicate Issue

This is being handled as part of http://jira.jboss.com/jira/browse/JBRULES-1089

> nested accessors with Sets - "not contains" is not a valid operator for MVEL
> ----------------------------------------------------------------------------
>
>                 Key: JBRULES-1058
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1058
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark McNally
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Following does not work:
> 		rule StateMatch
> 			when
> 			$ca:CandidateAssociation(nurseDetails.stateLicensures excludes patientDetails.state  )			
> 			then 	
> 				retract( $ca );
> 		end
> 		
> 		
> 		public class CandidateAssociation {
> 			private PatientDetails patientDetails;
> 			private NurseDetails   nurseDetails;
> 			private int overlapHours;
> 		
> 			public CandidateAssociation( PatientDetails patientDetails, NurseDetails nurseDetails) {
> 				super();
> 				this.patientDetails = patientDetails;
> 				this.nurseDetails = nurseDetails;
> 				overlapHours = participantDetails.getNumberOverlapHourCnt(nurseDetails);
> 			}
> 		    [...]
> 		}
> 		
> 		public class NurseDetails {
> 			private Set stateLicensures = new HashSet();
> 			[...]
> 		}
> 		public class PatientDetails {
> 			private String state;
> 			[...]
> 		}
> Edson suggested that the problem is that "not contains" is not a valid operator for MVEL. 
> Also Noticed that the following workaround did not work:
> 		rule State
> 		    dialect "mvel"
> 			when
> 		            $ca:CandidateAssociation( eval ( ! nurseDetails.stateLicensures.contains( patientDetails.state ) ) )
> 			then 	
> 		  	    retract( $ca );
> 		end
> 		
> 		This produced this Exception:
> 		org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=State, agendaGroup=MAIN, salience=0, no-loop=false]
> 	        at org.drools.rule.Package.checkValidity(Package.java:408)
> 	        at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	        at [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 09:12:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 09:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28239360.1187788338327.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=all ]

Edson Tirelli reassigned JBRULES-1091:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 09:15:51 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Aug 2007 09:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-203) Primary Partiton
 approach for handling of partitions
Message-ID: <13189356.1187788551148.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-203?page=comments#action_12373306 ] 
            
Bela Ban commented on JGRP-203:
-------------------------------

I don't see why PRIMARY_PARTITION needs to sort the MergeView is receives: a MergeView is only created by the *merge leader*, and therefore it will be exactly the same on all merge cordinators.
So we don't need to sort it.
A much simpler implementation could be to deterministically find out the primary partition and then send EXIT events to all members in non-primary partitions.
Even simpler: there could be an option in JChannel that triggers an EXIT if we're not in the primary partition on reception of a MergeView. User code could be called to determine the primary partition

> Primary Partiton approach for handling of partitions
> ----------------------------------------------------
>
>                 Key: JGRP-203
>                 URL: http://jira.jboss.com/jira/browse/JGRP-203
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: PRIMARY_PARTITION.java
>
>
> Add this approach to JGroups. Members in a non-primary partition will shut down, become read-only etc.
> Google for "primary partition AND group communication" for the relevant literature on 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 lists.jboss.org  Wed Aug 22 09:51:22 2007
From: jira-events at lists.jboss.org (Tobias Roth (JIRA))
Date: Wed, 22 Aug 2007 09:51:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1646) portal-cms
 depends on existence of user 'admin'
Message-ID: <23503800.1187790682411.JavaMail.jira@cloud.prod.atl2.jboss.com>

portal-cms depends on existence of user 'admin'
-----------------------------------------------

                 Key: JBPORTAL-1646
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1646
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.6.1 Final
            Reporter: Tobias Roth
         Assigned To: Sohil Shah


cms/src/main/org/jboss/portal/cms/impl/jcr/JCRCMS.java has the user 'admin' hardcoded:


   /** Loads content from sar and adds it to the repo. */
   public void createContent() throws Exception
   {
      log.info("Creating default CMS content.");
      

      // Get the content
      URL root = Thread.currentThread().getContextClassLoader().getResource(defaultContentLocation);

      
      //make the user executing these to create the default content, an 'Admin' user
      //without this, the fine grained security won't allow the creation
      UserModule userModule = getUserModule();
      if(userModule != null)
      {
	      org.hibernate.Session session = org.jboss.portal.cms.hibernate.state.Tools.getOpenSession();
	      org.hibernate.Transaction tx = session.beginTransaction();
	      User user = userModule.findUserByUserName("admin"); // HERE
	      if(user!=null)
	      {
	    	  JCRCMS.getUserInfo().set(user);
	      }
	      tx.rollback();
	      org.jboss.portal.cms.hibernate.state.Tools.closeSession(session);
      }	


If it doesn't exist (for example because LDAP is being used), portal-cms cannopt be deployed, and several database tables are not created. If 'admin' is changed to an existing user, everything works fine.

There is another reference to 'admin' in cms/src/main/org/jboss/portal/cms/impl/jcr/command/ACLEnforcer.java, but leaving this as it is doesn't seem to have any negative 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 lists.jboss.org  Wed Aug 22 10:45:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 10:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-259) Migrate AOP builds
	to maven
Message-ID: <18720598.1187793918279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-259?page=all ]

Paul Gier updated JBBUILD-259:
------------------------------

    Summary: Migrate AOP builds to maven  (was: AOP pom)

> Migrate AOP builds to maven
> ---------------------------
>
>                 Key: JBBUILD-259
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-259
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>          Time Spent: 1 day
>  Remaining Estimate: 3 days
>
> Migrate AOP builds to maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 11:20:18 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 22 Aug 2007 11:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1045) test suite has to
 trow a runtime exception on error so meaningful report is generated
Message-ID: <1738376.1187796018337.JavaMail.jira@cloud.prod.atl2.jboss.com>

test suite has to trow a runtime exception on error so meaningful report is generated
-------------------------------------------------------------------------------------

                 Key: JBPM-1045
                 URL: http://jira.jboss.com/jira/browse/JBPM-1045
             Project: JBoss jBPM
          Issue Type: Bug
    Affects Versions: jBPM jPDL 3.2.2
            Reporter: Aleksandar Kostadinov
         Assigned To: Tom Baeyens


When there are test suite initialization problems, test suite ignores exception (just prints it to the output) that causes junit to crash. 

I identified the issue in the following files:

jpdl/jar/src/test/java/org/jbpm/AllDBTests.java
jpdl/jar/src/test/java/org/jbpm/AllTests.java
have to have "throw t;" after "t.printStackTrace();"

As well the following test cases seem suspicious to me. I mean I'm not sure if an exception by these tests will cause a test suite crash. Please inspect if trowing an axception is desirable after printStackTrace method is used in these files:
./msg/command/AsyncExecutionDbTest.java
./perf/MemLeakTest.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 lists.jboss.org  Wed Aug 22 11:26:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 11:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18010504.1187796378850.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1055?page=comments#action_12373328 ] 
            
Edson Tirelli commented on JBRULES-1055:
----------------------------------------

This is actually a documentation problem and not a bug. DSL was augmented in Drools 4.0 to support regexps as part of the mappings. This intents to make DSL mappings more robust and allowing users to handle more situations with less effort. For instance, if you want to handle multiple values, you could write a mapping like:

[when][]Customer code is [ABCD]=Customer( code == "premium")

The above mapping will match any of the following statements:

Customer code is A
Customer code is B
Customer code is C
Customer code is D

As [ABCD] is interpreted as a regexp.

So, in your case, the only fix you need to do is escape your [] in the same way you escape them in regular expressions. Look at the following example:

[when][]attr {attr_name} is in \[ {values} \]={attr_name} in ( {values} )

The above mapping will match:

attr name is in [ 'Edson', 'Bob' ]

And translate that into:

name in ( 'Edson', 'Bob' )

I will look at fixing documentation. This is not backward compatible, but we feel the added flexibility was worth breaking the compatibility in the major version release.


> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 11:59:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 11:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8419534.1187798358222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4563?page=all ]

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Assignee:     (was: Carlo de Wolf)

Is this the latest version we can use?

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:01:28 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:01:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4568) AOP 2.0.0.beta
In-Reply-To: <31447129.1184845427146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3391727.1187798488015.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4568?page=comments#action_12373331 ] 
            
Dimitris Andreadis commented on JBAS-4568:
------------------------------------------

Is 2.2.0.beta still the target AOP release? (currently on snapshot)

> AOP 2.0.0.beta
> --------------
>
>                 Key: JBAS-4568
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4568
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: AOP
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:01:28 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:01:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4392) Replace j2ee and
 ejb3x module with javaee module
In-Reply-To: <14393824.1178194240545.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29185819.1187798488707.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4392?page=comments#action_12373332 ] 
            
Dimitris Andreadis commented on JBAS-4392:
------------------------------------------

Is there more work to it?

> Replace j2ee and ejb3x module with javaee module
> ------------------------------------------------
>
>                 Key: JBAS-4392
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4392
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:01:28 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 12:01:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
In-Reply-To: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24599972.1187798488841.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-403?page=all ]

Paul Gier reassigned JBBUILD-403:
---------------------------------

    Assignee: Paul Gier

> Add config parameter to specify groupId in jboss deploy plugin
> --------------------------------------------------------------
>
>                 Key: JBBUILD-403
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-deploy-plugin
>    Affects Versions: maven-jboss-deploy-plugin-1.3
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:03:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2853) Integrate JBoss
 Cache 2.0 into AS 5.0
Message-ID: <22950696.1187798598321.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2853?page=comments#action_12373333 ] 
            
Dimitris Andreadis commented on JBAS-2853:
------------------------------------------

I see the trunk moved to 2.0.0.GA.

Are we updating JGroups, too? (2.5)

> Integrate JBoss Cache 2.0 into AS 5.0
> -------------------------------------
>
>                 Key: JBAS-2853
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2853
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBoss Cache
>            Reporter: Manik Surtani
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> JBC 2.0.0.ALPHA1 was produced for JB5, Beta1.
> I'm assigning this issue to the next beta, to track further integration 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 lists.jboss.org  Wed Aug 22 12:03:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 22 Aug 2007 12:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19938937.1187798598452.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4567?page=comments#action_12373334 ] 
            
Dimitris Andreadis commented on JBAS-4567:
------------------------------------------

Is the target 2.1.0 or 2.0.1 ?

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:14:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 12:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-403) Add config
 parameter to specify groupId in jboss deploy plugin
In-Reply-To: <4300210.1187728398220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17580067.1187799258304.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-403?page=all ]

Paul Gier closed JBBUILD-403.
-----------------------------

    Resolution: Done

Added a groupId parameter.

> Add config parameter to specify groupId in jboss deploy plugin
> --------------------------------------------------------------
>
>                 Key: JBBUILD-403
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-403
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: maven-jboss-deploy-plugin
>    Affects Versions: maven-jboss-deploy-plugin-1.3
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add a parameter to use a different groupId.  This will allow deployment to the jboss directory when the maven groupId is "org.jboss.something".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 12:16:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Aug 2007 12:16:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2853) Integrate JBoss
 Cache 2.0 into AS 5.0
Message-ID: <24662415.1187799379910.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2853?page=comments#action_12373339 ] 
            
Brian Stansberry commented on JBAS-2853:
----------------------------------------

I have to sort it out with Tim Fox, i.e. get consensus on adding it to the JBM component-info.xml. Otherwise build breaks. We chatted a bit about that around beg of July, but it got somewhat sidetracked with some discussion about JBM in 4.2. ;)  I'll ping him again.

> Integrate JBoss Cache 2.0 into AS 5.0
> -------------------------------------
>
>                 Key: JBAS-2853
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2853
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBoss Cache
>            Reporter: Manik Surtani
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> JBC 2.0.0.ALPHA1 was produced for JB5, Beta1.
> I'm assigning this issue to the next beta, to track further integration 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 lists.jboss.org  Wed Aug 22 12:16:20 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Aug 2007 12:16:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-406) Create retro
	build for aop
In-Reply-To: <1127269.1187729719337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3103798.1187799380172.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-406?page=all ]

Paul Gier reassigned JBBUILD-406:
---------------------------------

    Assignee: Paul Gier

> Create retro build for aop
> --------------------------
>
>                 Key: JBBUILD-406
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-406
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> AOP needs a retro 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 lists.jboss.org  Wed Aug 22 12:24:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 12:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27531961.1187799858450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373341 ] 
            
Edson Tirelli commented on JBRULES-1091:
----------------------------------------

Not sure what we can do about this, since a null value is not a valid "fact" for the engine, and as such, it can't reason over it...

Anyone want to suggest something?


> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 12:33:36 2007
From: jira-events at lists.jboss.org (davide pasinato (JIRA))
Date: Wed, 22 Aug 2007 12:33:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4621) error deploying
 admin-consoles in deploy is a link
Message-ID: <10186901.1187800416294.JavaMail.jira@cloud.prod.atl2.jboss.com>

error deploying admin-consoles in deploy is a link
--------------------------------------------------

                 Key: JBAS-4621
                 URL: http://jira.jboss.com/jira/browse/JBAS-4621
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Console
    Affects Versions: JBossAS-4.2.1.GA
         Environment: linux RH-4 Sun jdk 1.5 jboss 4.2.1 server: all with jbossws-2.0.1
            Reporter: davide pasinato
         Assigned To: Darran Lofthouse
            Priority: Minor


I have a cluster of two jboss 4.2.1 servers. They run on the same machine. For this reason the server B links the directories deploy and lib of the server A when I start server A everything run smoothly. When I start server B I get an exception deploying the administration consoles. Looks like the directory management doesnt like symbolic links. 

This is the exception I get on server B (the root directory of server B is /var/opt/jboss/stress1b):

org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute at e5f0d2 on mbean jboss.admin:service=DeploymentFileRepository; - nested throwable: (java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b')
        at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:698)
        at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:332)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
        at org.jboss.system.ServiceController.install(ServiceController.java:226)
        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.install(Unknown Source)
        at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
        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 $Proxy9.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.GeneratedMethodAccessor4.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.GeneratedMethodAccessor10.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:508)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b'
        at org.jboss.console.manager.DeploymentFileRepository.getFile(DeploymentFileRepository.java:151)
        at org.jboss.console.manager.DeploymentFileRepository.setBaseDir(DeploymentFileRepository.java:124)
        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.AttributeDispatcher.invoke(AttributeDispatcher.java:136)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
        at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:103)
        at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
        at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608)
        at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:694)
        ... 84 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 lists.jboss.org  Wed Aug 22 12:46:18 2007
From: jira-events at lists.jboss.org (davide pasinato (JIRA))
Date: Wed, 22 Aug 2007 12:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4621) error deploying
 admin-consoles in deploy is a link
In-Reply-To: <10186901.1187800416294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20634104.1187801178571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4621?page=all ]

davide pasinato updated JBAS-4621:
----------------------------------


To better explain my enviroment (to help you to reproduce my problem) this is the structure of my server B

ls /var/opt/jboss/stress1b

conf -> ../stress1a/conf
data
deploy -> ../stress1a/deploy
farm
lib -> ../stress1a/lib
log
tmp
work

while server A is a standard server whose server root directory is /var/opt/jboss/stress1a

> error deploying admin-consoles in deploy is a link
> --------------------------------------------------
>
>                 Key: JBAS-4621
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4621
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.2.1.GA
>         Environment: linux RH-4 Sun jdk 1.5 jboss 4.2.1 server: all with jbossws-2.0.1
>            Reporter: davide pasinato
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>
> I have a cluster of two jboss 4.2.1 servers. They run on the same machine. For this reason the server B links the directories deploy and lib of the server A when I start server A everything run smoothly. When I start server B I get an exception deploying the administration consoles. Looks like the directory management doesnt like symbolic links. 
> This is the exception I get on server B (the root directory of server B is /var/opt/jboss/stress1b):
> org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute at e5f0d2 on mbean jboss.admin:service=DeploymentFileRepository; - nested throwable: (java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b')
>         at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:698)
>         at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:332)
>         at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>         at org.jboss.system.ServiceController.install(ServiceController.java:226)
>         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.install(Unknown Source)
>         at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
>         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 $Proxy9.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.GeneratedMethodAccessor4.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.GeneratedMethodAccessor10.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:508)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalArgumentException: child './deploy/management' should be a child of parent '/var/opt/jboss/stress1b'
>         at org.jboss.console.manager.DeploymentFileRepository.getFile(DeploymentFileRepository.java:151)
>         at org.jboss.console.manager.DeploymentFileRepository.setBaseDir(DeploymentFileRepository.java:124)
>         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.AttributeDispatcher.invoke(AttributeDispatcher.java:136)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:103)
>         at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
>         at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608)
>         at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:694)
>         ... 84 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 lists.jboss.org  Wed Aug 22 12:54:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 22 Aug 2007 12:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4568) AOP 2.0.0.beta
In-Reply-To: <31447129.1184845427146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16275349.1187801658239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4568?page=comments#action_12373353 ] 
            
Kabir Khan commented on JBAS-4568:
----------------------------------

Yes, and we'll get the beta out

> AOP 2.0.0.beta
> --------------
>
>                 Key: JBAS-4568
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4568
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: AOP
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 13:14:18 2007
From: jira-events at lists.jboss.org (=?UTF-8?Q?Jacques_Desmazi=EF=BF=A8res_=28JIRA=29?=)
Date: Wed, 22 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1046) JobExecutorServlet
 cannot use local JNDI name to access fatasource
Message-ID: <10473705.1187802858662.JavaMail.jira@cloud.prod.atl2.jboss.com>

JobExecutorServlet cannot use local JNDI name to access fatasource
------------------------------------------------------------------

                 Key: JBPM-1046
                 URL: http://jira.jboss.com/jira/browse/JBPM-1046
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM jPDL 3.2.1
         Environment: Windows 2000
IBM Websphere Application Server 6.1 (also reproduced on Websphere Test Environment 5.1)
Oracle 9i database (with ojdbc14.jar release 9.2.0.8)

            Reporter: Jacques Desmazi?res
         Assigned To: Tom Baeyens
             Fix For:  jBPM jPDL 3.2.1


When configuraing jBPM / Hibernate with a datasource in an Enterprise application, using a local JNDI reference (java:comp/env/...) the web application works properly, accessing the database without any problem. 

But if you declare the JobExecutorServlet in the web application's web.xml, each time the this servlet JobExecutorThread fires, it generates exceptions:

[22/08/07 18:33:03:175 CEST] 0000005e SystemOut     O 18:33:03 DEBUG org.jbpm.job.executor.JobExecutorThread : acquiring jobs for execution...
[22/08/07 18:33:03:315 CEST] 0000005f javaURLContex E   NMSV0310E: Une op?ration JNDI sur un nom "java:" ne peut pas aboutir car le contexte d'ex?cution du serveur ne peut pas associer l'unit? d'ex?cution de l'op?ration ? un composant d'application J2EE. Cette condition peut se produire lorsque le client JNDI utilisant le nom "java:" n'est pas ex?cut? sur l'unit? d'ex?cution d'une demande d'application du serveur. Assurez-vous qu'une application J2EE n'ex?cute pas d'op?rations JNDI sur des noms "java:" dans des blocs de code statiques ou dans des unit?s d'ex?cution cr??es par cette application J2EE. Un code de ce type ne s'ex?cute pas n?cessairement sur l'unit? d'ex?cution d'une demande d'application du serveur et n'est donc pas pris en charge par les op?rations JNDI sur les noms "java:". Trace de pile d'exceptions : 
javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
	at javax.naming.InitialContext.lookup(InitialContext.java:363)
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
Caused by: javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
	... 17 more
 
[22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 FATAL org.hibernate.connection.DatasourceConnectionProvider : Could not find datasource: java:comp/env/jdbc/dsJBPM
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
	at javax.naming.InitialContext.lookup(InitialContext.java:363)
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
Caused by: 
javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
	... 17 more
[22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 ERROR org.jbpm.job.executor.JobExecutorThread : exception in job executor thread. waiting 10000 milliseconds
org.hibernate.HibernateException: Could not find datasource
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:56)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
Caused by: 
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
	at javax.naming.InitialContext.lookup(InitialContext.java:363)
	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
	... 13 more
Caused by: 
javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
	... 17 more

The exception is raised even if there is no timer in the process definition.

If I replace the local JNDI reference (java:comp/env/jdbc/datasource) with the global JNDI name (jdbc/dsOracle) the JobExecutorThread works fine (even if Websphere logs warning due to direct use of the global JNDI reference). The JobExecutorThread also works if I replace the datasource with the database access parameters (driver, url, ...).


(sample ear is available to reproduce the bug if 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 lists.jboss.org  Wed Aug 22 13:30:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Wed, 22 Aug 2007 13:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1110) Rules with 'From'
 condition with another not using From causes problem
Message-ID: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rules with 'From' condition with another not using From causes problem
----------------------------------------------------------------------

                 Key: JBRULES-1110
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Decision tables, Reteoo
    Affects Versions:  4.0.0.GA
         Environment: Any
            Reporter: Arjun Dhar
         Assigned To: Mark Proctor


Test case:

Write a Rule that uses a From clause and on another object does not use a from clause:
example:
#From row number: 28
rule "Rules_28"
	
	when
		cntct: Contact(initialized==true)
		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
	then
                             System.out.println("Fired 28");
end

If All 3 are true:
 1. Delete Condition 2 --> Rule fires
 2. Delete COnditon 3 (But keep 2) --> Rule fires
 3. Keep 2 & 3 (with 1) --> Rule does not fire

Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.

Please see if it is 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 lists.jboss.org  Wed Aug 22 13:32:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Wed, 22 Aug 2007 13:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
Message-ID: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>

Final methods of POJO's aer never evaluated
-------------------------------------------

                 Key: JBRULES-1111
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Arjun Dhar
         Assigned To: Mark Proctor
            Priority: Minor


If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 13:50:33 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 22 Aug 2007 13:50:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-75)
 SecurityAssociation on the Client Side
Message-ID: <24127516.1187805033678.JavaMail.jira@cloud.prod.atl2.jboss.com>

SecurityAssociation on the Client Side
--------------------------------------

                 Key: SECURITY-75
                 URL: http://jira.jboss.com/jira/browse/SECURITY-75
             Project: JBoss Security and Identity Management
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0.1-BETA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1-GA


Clients may have done deeper integration with security association (in lieu of JAAS).  The principal/credential needs to be transferred into a 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 lists.jboss.org  Wed Aug 22 13:52:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 13:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1055) Regex-Special
 characters can not be used in DSLs.
In-Reply-To: <13321686.1186070269459.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18391261.1187805138378.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1055?page=all ]

Edson Tirelli closed JBRULES-1055.
----------------------------------

    Resolution: Done

I added a note on the Upgrade Tips section about DSL and unit tests just to make sure it was working.
The chapter on DSL still needs to be rewritten though.


> Regex-Special characters can not be used in DSLs.
> -------------------------------------------------
>
>                 Key: JBRULES-1055
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1055
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 5
>            Reporter: Michael Wiedmer
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Up until Drools 3.0.6 one could write DSLs to allow expressions such as
> EXAMPLE IS IN [ "one" "two"]
> This has changed now. The square brackes (being part of special characters for regular expressions) deny the DefaultDSLMappingEntry class to define a valid keyPattern.
> Here is a (not) working example, using the default sample project:
> 8<---- regexError.drl -----
> package some.test
> import com.sample.*;
> expander regexError.dsl
> rule "Test"
> 	when
> 		STRING "UK" IS IN < "USA", "UK", "GERMANY" >
> 	then 
> 		LOG "Square Brackets will not work."
> end
> 8<---- regexError.dsl -----
> [consequence][]LOG {msg}=System.out.println({msg});
> [condition][]STRING "{string}" IS IN < {sequence} >=eval(true == true)
> 8<---- DroolsTest.javal -----
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class DroolsTest {
>     public static final void main(String[] args) {
>         try {
>             // load up the rulebase
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             // go !
>             Message message = new Message();
>             message.setMessage("Hello World");
>             message.setStatus(Message.HELLO);
>             workingMemory.insert(message);
>             workingMemory.fireAllRules();
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.drl"));
>         Reader dsl = new InputStreamReader(DroolsTest.class.getResourceAsStream("/regexError.dsl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source, dsl);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> If one was to change the files regexError.dsl and regexError.drl and use square brackets instead of angle brackets, the DroolsTest will fail with the same error as shown in the Eclipse IDE:
> org.drools.rule.InvalidRulePackage: org.drools.lang.ExpanderException at 14c1103[9,2]: unknown:9:2 Unexpected token 'STRING'[9,22]: unknown:9:22 mismatched token: [@31,115:119='"USA"',<20>,9:22]; expecting type RIGHT_SQUARE[11,1]: unknown:11:1 mismatched token: [@43,150:155='System',<8>,11:1]; expecting type RIGHT_PAREN[11,20]: unknown:11:20 mismatched token: [@49,169:200='"Square Brackets will not work."',<20>,11:20]; expecting type RIGHT_PAREN[12,0]: unknown:12:0 mismatched token: [@53,205:207='end',<15>,12:0]; expecting type THEN
> 	at org.drools.rule.Package.checkValidity(Package.java:408)
> 	at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:288)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:44)
> 	at com.sample.DroolsTest.main(DroolsTest.java:18)
> It does not matter what the RHS of the DSL says, as the LHS will not be matched in DefaultExpander.expandLHS(final String lhs, int lineOffset), line 231.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 13:52:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 22 Aug 2007 13:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-75) SecurityAssociation
 on the Client Side
In-Reply-To: <24127516.1187805033678.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28729716.1187805138497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-75?page=all ]

Anil Saldhana closed SECURITY-75.
---------------------------------

    Resolution: Done

Running org.jboss.test.securityassociation.LegacySecurityAssociationTestCase
Found log4j.xml: file:/C:/cygwin/home/asaldhana/security/security-jboss-sx/trunk
/target/test-classes/log4j.xml
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 sec

> SecurityAssociation on the Client Side
> --------------------------------------
>
>                 Key: SECURITY-75
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-75
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.1-BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1-GA
>
>
> Clients may have done deeper integration with security association (in lieu of JAAS).  The principal/credential needs to be transferred into a 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 lists.jboss.org  Wed Aug 22 14:20:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Wed, 22 Aug 2007 14:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8242477.1187806818210.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4563?page=comments#action_12373366 ] 
            
Emmanuel Bernard commented on JBAS-4563:
----------------------------------------

No the latest version is 3.3.0
3.3.1 is due as soon as I have some spare time and is mostly bug fixing.
http://opensource.atlassian.com/projects/hibernate/browse/ANN?report=com.atlassian.jira.plugin.system.project:roadmap-panel

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:04:18 2007
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 22 Aug 2007 15:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-1045) test suite has to
 trow a runtime exception on error so meaningful report is generated
In-Reply-To: <1738376.1187796018337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23722263.1187809458294.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-1045?page=comments#action_12373378 ] 
            
Aleksandar Kostadinov commented on JBPM-1045:
---------------------------------------------

--- AllTests    2007-08-22 14:50:04.713887000 -0400
+++ AllTests.java       2007-08-22 14:57:25.335824000 -0400
@@ -36,7 +36,8 @@
       return suite;
     } catch (Throwable t) {
       t.printStackTrace();
-      return null;
+      throw new RuntimeException(t);
+      // return null;
     }
   }
 }

--- AllDbTests  2007-08-22 15:02:04.809038000 -0400
+++ AllDbTests.java     2007-08-21 10:18:22.329696000 -0400
@@ -84,6 +84,7 @@

     } catch (Throwable t) {
       t.printStackTrace();
+      throw new RuntimeException(t);
     }

Let me not give blind suggestions about both the other 2 files. Haven't looked into do code. These are lower priority.

> test suite has to trow a runtime exception on error so meaningful report is generated
> -------------------------------------------------------------------------------------
>
>                 Key: JBPM-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1045
>             Project: JBoss jBPM
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL 3.2.2
>            Reporter: Aleksandar Kostadinov
>         Assigned To: Tom Baeyens
>
> When there are test suite initialization problems, test suite ignores exception (just prints it to the output) that causes junit to crash. 
> I identified the issue in the following files:
> jpdl/jar/src/test/java/org/jbpm/AllDBTests.java
> jpdl/jar/src/test/java/org/jbpm/AllTests.java
> have to have "throw t;" after "t.printStackTrace();"
> As well the following test cases seem suspicious to me. I mean I'm not sure if an exception by these tests will cause a test suite crash. Please inspect if trowing an axception is desirable after printStackTrace method is used in these files:
> ./msg/command/AsyncExecutionDbTest.java
> ./perf/MemLeakTest.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 lists.jboss.org  Wed Aug 22 15:28:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 15:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1065) Unable to return
 Declaration for identifier
In-Reply-To: <5845918.1186552069356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21937175.1187810898471.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1065?page=all ]

Edson Tirelli closed JBRULES-1065.
----------------------------------

    Resolution: Done

Added support for autovivification in variable restrictions. This is now working:

rule "autovivification"
when
     Cheese( price > oldPrice, price > this.oldPrice )
then
     results.add( "OK" );
end

Integration test added. 

Thanks for reporting.

> Unable to return Declaration for identifier
> -------------------------------------------
>
>                 Key: JBRULES-1065
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1065
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.6
>            Reporter: Tong Lee
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I've read in the 4.0 features list where implicit binding for value expressions will be available in the 4.0 release.  I've downloaded 4.0GA and still getting the compiler error.  We have a need for the following and wondering if I'm misunderstanding the functionality:
> Fact/bean object code:
> public class Record {
> private String abc;
> private String xyz;
> public String getAbc()...
> public String getXyz()...
> ...
> }
> DRL code:
> rule "..."
>   when
>     $record : Record ( abc == xyz)
>   then
>     ....
> end
> The PackageBuilder can not resolve the "xyz"
> I understand we can define the Record alias and then reference xyz using the alias (see example below) but it would be asking too much for our business users.
> rule "..."
>   when
>     r: Record ( )
>     $record : Record ( abc == r.xyz)
>   then
>     ....
> end
> Any feedback with this is greatly 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 lists.jboss.org  Wed Aug 22 15:30:22 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 15:30:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24073088.1187811022902.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1101?page=comments#action_12373382 ] 
            
Edson Tirelli commented on JBRULES-1101:
----------------------------------------

I did a few changes that may solve the problem as part of http://jira.jboss.com/jira/browse/JBRULES-1065. 
I'm closing the ticket. If the problem persists, please re-open the ticket and attach a sample rule.

Thanks for reporting.

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:30:23 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 15:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1101) MVEL direct
 property accessors being converted to a ReturnValueConstraint
In-Reply-To: <19694412.1187501521305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15775040.1187811023147.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1101?page=all ]

Edson Tirelli closed JBRULES-1101.
----------------------------------

    Resolution: Done

> MVEL direct property accessors being converted to a ReturnValueConstraint
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-1101
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1101
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Yuri de Wit
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> After narrowing down a performance issue with my drools app, I reached to the dev team and quickly it became clear that for some reason drools was not indexing my field constraints. After some investigation and some help from Conan  it became clear that one of the problem was that MVEL direct property accessors were being translated into a ReturnValueConstraint (afaik, an eval), which cannot be indexed by default.
> So I changed my rules to make sure that i used aliaes for the first 3 constrraints instead of property accessors and I was able to see trememdous perf improvements for my usecases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:34:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Aug 2007 15:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4622) Can't flush bad
 naming stub if no java.naming.provider.url specified
Message-ID: <5212830.1187811258275.JavaMail.jira@cloud.prod.atl2.jboss.com>

Can't flush bad naming stub if no java.naming.provider.url specified
--------------------------------------------------------------------

                 Key: JBAS-4622
                 URL: http://jira.jboss.com/jira/browse/JBAS-4622
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Naming
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3


The NamingContext class maintains a static cache of server-side naming stubs, keyed by the address:port of the server.  Entries from this cache are meant to be removed if an IOException is caught when invoking on the stub, thus ensuring that problem stubs are discarded and a new stub lookup is forced.

This cache clearing process breaks if java.naming.provider.url is not set.  The clearing algorithm is in NamingContext.removeServer(Hashtable) is a no-op if the naming environment does not include java.naming.provider.url.  Based on a comment on the method, the reasoning behind this is to avoid flushing the "local" (i.e. in-vm) server from the cache.  But, the way the naming acquisition process works, a direct ref to the in-vm server will never be stored in the cache anyway, so this distinction in not valid.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 15:41:25 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 22 Aug 2007 15:41:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
In-Reply-To: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26293061.1187811685862.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1164?page=comments#action_12373389 ] 
            
Manik Surtani commented on JBCACHE-1164:
----------------------------------------

Does this exist in 2.0.0.GA as well?

> NodeNotExistException with concurent put/remove operations
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1164
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: ConcurentOperationsTest.java
>
>
> When 2 Threads are putting/removing data from this same node, put operation fails with exception
> org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
> 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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
> 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:89) 
> 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) 
> (...) 
> Thread 1 is calling: 
> 	cache.remove("/a/b/c/d");
> 	cache.remove("/a");
>  Thread 2 is calling: 
> 	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Wed Aug 22 15:41:26 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Wed, 22 Aug 2007 15:41:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1166)
 UpgradeException on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12051884.1187811686117.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=comments#action_12373390 ] 
            
Manik Surtani commented on JBCACHE-1166:
----------------------------------------

Is this just a PojoCache bug?  What happens with core cache in this case?

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Wed Aug 22 16:20:18 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Wed, 22 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31795580.1187814018319.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373396 ] 
            
Alexandre Gattiker commented on JBRULES-1091:
---------------------------------------------

The intent of the actual business rule that spawned the bug was to use Drools to perform aggregation, in a similar way to a SQL query. Something like

when
$c:Customer()
$totalPayments:Money()
   from accumulate( Payment ( customer == $c) ...
then
  ...do something with $totalPayments...

The result can be null. Obviously, using Drools syntax rather than collecting Payments in the RHS is mostly a convenience (though it might bring a performance boost in some cases).

The bug can be resolved easily by handling the null value in the hashCode call in DefaultFactHandle. But I assume that you worry about the case when constraints are placed on the accumulated value.

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 16:24:29 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Wed, 22 Aug 2007 16:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1164)
 NodeNotExistException with concurent put/remove operations
In-Reply-To: <18249492.1187299741540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26044471.1187814269909.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1164?page=comments#action_12373397 ] 
            
Jacek Halat commented on JBCACHE-1164:
--------------------------------------

yes, this exists in 2.0.0 GA, but because put/remove operations are replaced with attach/detach and in 2.0.0 GA another exception is thrown (UpgradeException) another issue was created (JBCACHE-1164). (Probably this is this same bug but exception for user is another)

> NodeNotExistException with concurent put/remove operations
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1164
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: ConcurentOperationsTest.java
>
>
> When 2 Threads are putting/removing data from this same node, put operation fails with exception
> org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main]) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4618) 
> at org.jboss.cache.TreeCache._put(TreeCache.java:4579) 
> 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 org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) 
> 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:89) 
> 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) 
> (...) 
> Thread 1 is calling: 
> 	cache.remove("/a/b/c/d");
> 	cache.remove("/a");
>  Thread 2 is calling: 
> 	cache.putObject("/a/b/c/d", "text" + 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 lists.jboss.org  Wed Aug 22 16:36:29 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 22 Aug 2007 16:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1035) get latest
	tutorials online
Message-ID: <18674529.1187814989070.JavaMail.jira@cloud.prod.atl2.jboss.com>

get latest tutorials online
---------------------------

                 Key: EJBTHREE-1035
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1035
             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 lists.jboss.org  Wed Aug 22 16:38:18 2007
From: jira-events at lists.jboss.org (krish p (JIRA))
Date: Wed, 22 Aug 2007 16:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1279) shutdown -u -p
 options are not working
Message-ID: <17580009.1187815098802.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1279?page=comments#action_12373400 ] 
            
krish p commented on JBAS-1279:
-------------------------------

Is this fixed in 4.0.5? I see this issue when JBoss Portal 2.6 is deployed in JBoss and I try running "shutdown.sh -S -u admin". I've used a custom security realm and updated jmx-invoker-service.xml accordingly.

> shutdown -u -p options are not working
> --------------------------------------
>
>                 Key: JBAS-1279
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1279
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Wonne Keysers
>         Assigned To: Scott M Stark
>             Fix For:  JBossAS-4.0.2RC1
>
>
> This feature does work in 3.2.x, but is apparently not yet implemented in 4.0.1 ?
> Unable to shutdown the server when the following is commented out in jmx-invoker-service.xml:
> <descriptors>
>    <interceptors>
> 	  <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
> 		 securityDomain="java:/jaas/jmx-console"/>
>    </interceptors>
> </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 lists.jboss.org  Wed Aug 22 16:47:21 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Wed, 22 Aug 2007 16:47:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1166)
 UpgradeException on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4642714.1187815641558.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=comments#action_12373401 ] 
            
Jacek Halat commented on JBCACHE-1166:
--------------------------------------

Stack trace for core cache:

org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/a/b/c/d, caller=GlobalTransaction:<null>:4, lock=write owner=GlobalTransaction:<null>:3 (activeReaders=0, activeWriter=Thread[Thread-2,5,main], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:528)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1581)
	at org.jboss.cache.aop.ConcurentOperationTestPojo$WorkThread.run(ConcurentOperationTestPojo.java:83)
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /a/b/c/d could not be acquired after 10000 ms. Locks: Read lock owners: []
Write lock owner: GlobalTransaction:<null>:3
 (caller=GlobalTransaction:<null>:4, lock info: write owner=GlobalTransaction:<null>:3 (activeReaders=0, activeWriter=Thread[Thread-2,5,main], waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:244)
	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
	... 17 more



> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java, ConcurentOperationTestCore.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Wed Aug 22 16:47:21 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Wed, 22 Aug 2007 16:47:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1166) UpgradeException
 on concurent put/remove operation
In-Reply-To: <33448482.1187338441457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7875992.1187815641763.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1166?page=all ]

Jacek Halat updated JBCACHE-1166:
---------------------------------

    Attachment: ConcurentOperationTestCore.java

Test for core cache

> UpgradeException on concurent put/remove operation
> --------------------------------------------------
>
>                 Key: JBCACHE-1166
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>         Environment: Windows XP, Sun jdk150_06 
>            Reporter: Jacek Halat
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>         Attachments: ConcurentOperationTest.java, ConcurentOperationTestCore.java
>
>
> When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
> upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> Full StackTrace:
> org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
> 	at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
> Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
> 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
> 	at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
> 	at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
> 	at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
> 	at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
> 	... 5 more
> Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
> 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
> 	... 25 more
> Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
> 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
> 	at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
> 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
> 	... 27 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 lists.jboss.org  Wed Aug 22 16:54:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 16:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31495300.1187816058379.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373405 ] 
            
Edson Tirelli commented on JBRULES-1091:
----------------------------------------

Alexander,

Yes, the problem is exactly further constraints on the null value.

I understand that in sql the result could be null, but in drools, it should only be null if the user does it on purpose, what would be wrong. Such accumulations are always initialized in the init block:

when
$c:Customer()
$totalPayments:Money()
   from accumulate( Payment ( customer == $c, $val : value )
                                   init( Money total = new Money( 0 ); )
                                   action( total.add( $val ); )
                                   reverse( total.subtract( $val ); )
                                   result( total ) )
then 
   // ...
end

Is my assumption wrong?

So, maybe we can add a null check, so that we can provide a user friendly error message, but allowing null into the engine has huge drawbacks.

On an unrelated note, did you saw the accumulate functions feature? It may be interesting for you, doing things like:

when
$c:Customer()
$totalPayments:Number()
   from accumulate( Payment ( customer == $c, $val : value )
                                   sum( $val ) )
then 
   // ...
end

You can also create your own functions in case you want to return custom objects like the Money object in your example.



> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Wed Aug 22 17:13:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 22 Aug 2007 17:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1089) Getting "could not
 access property ('=')" for a valid rule.
In-Reply-To: <19659276.1187247541414.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18400973.1187817198411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1089?page=all ]

Edson Tirelli closed JBRULES-1089.
----------------------------------

    Resolution: Done

MVEL is fixed, so closing the ticket.

> Getting "could not access property ('=')" for a valid rule.
> -----------------------------------------------------------
>
>                 Key: JBRULES-1089
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1089
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: WinXP, Java 1.6.0 (Sun), running within Eclipse 3.2.2
>            Reporter: Arsalan Zaidi
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> From: rules-users-bounces at lists.jboss.org on behalf of Edson Tirelli [tirelli at post.com]
> Sent: 13 August 2007 22:16
> To: Rules Users List
> Subject: Re: [rules-users] could not access property ('=')
> Attachments: ATT426765.txt
>    This looks like an MVEL issue, since your expression is being converted into an MVEL predicate. May I ask you please to open a JIRA for that bug?
>    Meanwhile, a workaround that shall work for you and may give you improved perf is to split your pattern into 2 patterns using the from keyword: 
> when
>            $dto : DTO( )
>            W250_4_1( value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) ) from $dto.w250_4_1
> then
>    Thanks, and hope it helps.
>    Edson
> 2007/8/13, Arsalan S. Zaidi < arsalan.zaidi at capgemini.com>:
>   Hi.
>   I've currently evaluating Drools 4.0 for a project of ours and I'm running into some problems.
>   I have a rule which looks like this:
>   rule "W250.42 Editable"
>         when
>               DTO(w250_4_1.value in ("0" ,"1" ,"6" ,"7" ,"A" ,"C" ,"D" ,"G" ,"L" ,"M" ,"P" ,"Q" ,"S" ,"V" ,"Z" ) )
>         then
>               System.out.println ("0" );
>               Action action = createAction("W250.42" , false , true );
>               retList.add(action); 
>   end 
>   both DTO and w250_4_1 are extremely simple beans. w250_4_1 just has 1 property 'value' which is a String and DTO has one property w250_4_1 which is the bean w250_4_1 .
>   Now when I put "0" into w250_4_1 then everything works fine. The rule is true and the 'then' portion is executed. However, if I set w250_4_1 to "6" (which is also present in the in (...)) then I get the following error.
>   org.drools.RuntimeDroolsException : Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 118fa47
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:197 )
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122 )
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317 )
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168 )
>         at org.drools.reteoo.Rete.assertObject(Rete.java:168 )
>         at org.drools.reteoo.ReteooRuleBase.assertObject( ReteooRuleBase.java:190) 
>         at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822 )
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623 )
>         at com.sample.DroolsTest.main( DroolsTest.java:34)
>   Caused by: org.mvel.PropertyAccessException: failed to access property: <<==>> in: class com.sample.DTOShadowProxy
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:137 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:96 )
>         at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:194 )
>         at org.mvel.ast.Or.getReducedValueAccelerated(Or.java:18 )
>         at org.mvel.MVELRuntime.execute( MVELRuntime.java:87)
>         at org.mvel.CompiledExpression.getValue( CompiledExpression.java:98) 
>         at org.mvel.MVEL.executeExpression( MVEL.java:202)
>         at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36 )
>         at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:191 )
>         ... 10 more
>   Caused by: org.mvel.PropertyAccessException: could not access property ('=') 
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:252 )
>         at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:106 )
>         ... 18 more
>   If I keep w250_4_1 as "0", but move "0" in the rule to any other place place in the in() list (e.g. in ("1","0",...), then I get a similar error.
>   I get similar errors when trying to use 'not in' in the same circumstance, except that then the property is ('!')
>   What seems to be the issue?
>   Thanks in advance!
>   Regards,
>   --Arsalan
>         This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. 
>        
>   _______________________________________________
>   rules-users mailing list
>   rules-users at lists.jboss.org 
>   https://lists.jboss.org/mailman/listinfo/rules-users
> -- 
>   Edson Tirelli
>   Software Engineer - JBoss Rules Core Developer
>   Office: +55 11 3529-6000
>   Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat @ www.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 lists.jboss.org  Wed Aug 22 17:15:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Wed, 22 Aug 2007 17:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1046) JobExecutorServlet
 cannot use local JNDI name to access datasource
In-Reply-To: <10473705.1187802858662.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10127208.1187817318587.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1046?page=all ]

Ronald van Kuijk updated JBPM-1046:
-----------------------------------

                   Summary: JobExecutorServlet cannot use local JNDI name to access datasource  (was: JobExecutorServlet cannot use local JNDI name to access fatasource)
    Workaround Description: workaround exists by using the source and changing the datasource jndi name
             Fix Version/s: jBPM 3.3
                                (was:  jBPM jPDL 3.2.1)

> JobExecutorServlet cannot use local JNDI name to access datasource
> ------------------------------------------------------------------
>
>                 Key: JBPM-1046
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1046
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>         Environment: Windows 2000
> IBM Websphere Application Server 6.1 (also reproduced on Websphere Test Environment 5.1)
> Oracle 9i database (with ojdbc14.jar release 9.2.0.8)
>            Reporter: Jacques Desmazi?res
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.3
>
>
> When configuraing jBPM / Hibernate with a datasource in an Enterprise application, using a local JNDI reference (java:comp/env/...) the web application works properly, accessing the database without any problem. 
> But if you declare the JobExecutorServlet in the web application's web.xml, each time the this servlet JobExecutorThread fires, it generates exceptions:
> [22/08/07 18:33:03:175 CEST] 0000005e SystemOut     O 18:33:03 DEBUG org.jbpm.job.executor.JobExecutorThread : acquiring jobs for execution...
> [22/08/07 18:33:03:315 CEST] 0000005f javaURLContex E   NMSV0310E: Une op?ration JNDI sur un nom "java:" ne peut pas aboutir car le contexte d'ex?cution du serveur ne peut pas associer l'unit? d'ex?cution de l'op?ration ? un composant d'application J2EE. Cette condition peut se produire lorsque le client JNDI utilisant le nom "java:" n'est pas ex?cut? sur l'unit? d'ex?cution d'une demande d'application du serveur. Assurez-vous qu'une application J2EE n'ex?cute pas d'op?rations JNDI sur des noms "java:" dans des blocs de code statiques ou dans des unit?s d'ex?cution cr??es par cette application J2EE. Un code de ce type ne s'ex?cute pas n?cessairement sur l'unit? d'ex?cution d'une demande d'application du serveur et n'est donc pas pris en charge par les op?rations JNDI sur les noms "java:". Trace de pile d'exceptions : 
> javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
> 	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:363)
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
> 	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
> 	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
> 	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
> 	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
> 	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
> 	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
> 	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
> 	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
> Caused by: javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
> 	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
> 	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
> 	... 17 more
>  
> [22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 FATAL org.hibernate.connection.DatasourceConnectionProvider : Could not find datasource: java:comp/env/jdbc/dsJBPM
> javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
> 	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:363)
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
> 	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
> 	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
> 	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
> 	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
> 	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
> 	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
> 	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
> 	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
> Caused by: 
> javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
> 	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
> 	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
> 	... 17 more
> [22/08/07 18:33:03:347 CEST] 0000005e SystemOut     O 18:33:03 ERROR org.jbpm.job.executor.JobExecutorThread : exception in job executor thread. waiting 10000 milliseconds
> org.hibernate.HibernateException: Could not find datasource
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:56)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
> 	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
> 	at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.java:410)
> 	at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:62)
> 	at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
> 	at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:91)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94)
> 	at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:98)
> 	at org.jbpm.persistence.db.DbPersistenceService.getJobSession(DbPersistenceService.java:354)
> 	at org.jbpm.JbpmContext.getJobSession(JbpmContext.java:563)
> 	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:109)
> 	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
> Caused by: 
> javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the serverruntime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
> 	at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:416)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
> 	at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:363)
> 	at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)
> 	... 13 more
> Caused by: 
> javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
> 	at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
> 	at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
> 	at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
> 	at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
> 	... 17 more
> The exception is raised even if there is no timer in the process definition.
> If I replace the local JNDI reference (java:comp/env/jdbc/datasource) with the global JNDI name (jdbc/dsOracle) the JobExecutorThread works fine (even if Websphere logs warning due to direct use of the global JNDI reference). The JobExecutorThread also works if I replace the datasource with the database access parameters (driver, url, ...).
> (sample ear is available to reproduce the bug if 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 lists.jboss.org  Wed Aug 22 18:22:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Wed, 22 Aug 2007 18:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
Message-ID: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
-----------------------------------------------------------------------------------------------------

                 Key: JBAS-4623
                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-4.2.2.GA
            Reporter: William DeCoste
         Assigned To: Remy Maucherat


MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().

Let me know if you see what I mean - I can fix it. 

I'm looking in Branch_4_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 lists.jboss.org  Wed Aug 22 18:24:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Wed, 22 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9298528.1187821458324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1109?page=all ]

Fernando Meyer reassigned JBRULES-1109:
---------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Fernando Meyer
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 18:33:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 22 Aug 2007 18:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1031) Potential bug
 in cancelling delivery
In-Reply-To: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20566303.1187821998271.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1031?page=all ]

Clebert Suconic updated JBMESSAGING-1031:
-----------------------------------------

    Attachment: test.patch

to modify ejb3mdb to replicate this issue, apply this patch...

use:

patch -p0 < test.patch on the project root dir

> Potential bug in cancelling delivery
> ------------------------------------
>
>                 Key: JBMESSAGING-1031
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>         Attachments: test.patch
>
>
> Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 19:01:19 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 19:01:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-743) For polling
 callback handler, 
 org.jboss.remoting.Client.addListener() should create only one
 CallbackPoller per InvokerCallbackHandler
In-Reply-To: <28950543.1178341672458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5525766.1187823679030.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-743?page=comments#action_12373418 ] 
            
Ron Sigal commented on JBREM-743:
---------------------------------

Unit test:  org.jboss.test.remoting.callback.pull.UniqueCallbackPollerTestCase.

> For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-743
>                 URL: http://jira.jboss.com/jira/browse/JBREM-743
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. 
> The semantics, according to Chapter 5 of the Remoting guide, should be
> If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect.
> So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 19:10:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 19:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15853214.1187824231591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-749?page=comments#action_12373420 ] 
            
Ron Sigal commented on JBREM-749:
---------------------------------

The address to which the secondary ServerSocket is bound is now the same as that to which the "primary" ServerSocket is bound. The address sent to the client to use in connecting to the secondary ServerSocket is taken from the server's InvokerLocator.  It follows that if the "clientConnectAddress" property is set, its value will be used for the secondary ServerSocket.  

Also, there are two new configurable parameters in the class org.jboss.remoting.transport.bisocket.Bisocket specific to the bisocket transport:

Code:

   public static final String SECONDARY_BIND_PORT = "secondaryBindPort";
   public static final String SECONDARY_CONNECT_PORT = "secondaryConnectPort";
	

SECONDARY_BIND_PORT determines which port the secondary ServerSocket binds to, and SECONDARY_CONNECT_PORT determines which port is sent to the client to use in connecting to the secondary ServerSocket. 

There are two advantages to the new configuration properties.  

1. Being able to specify the secondary connect address makes it possible to run a bisocket server behind a NAT router.

2. Being able to specify the secondary bind port makes it possible to run a bisocket server behind a firewall.

The changes have been implemented for the 2.2.2.GA release.  They need to be applied to the remoting_2_x branch.

Unit test:  org.jboss.test.remoting.callback.pull.UniqueCallbackPollerTestCase.

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 19:56:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 19:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26421592.1187826978213.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-771?page=comments#action_12373424 ] 
            
Ron Sigal commented on JBREM-771:
---------------------------------

The fix is add a line to MicroSocketClientInvoker.handleDisconnect() so that it explicitly clears its own pool by calling clearPool(pool);



> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 20:21:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13381041.1187828478222.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-771?page=comments#action_12373427 ] 
            
Ron Sigal commented on JBREM-771:
---------------------------------

The fix has been applied to the remoting_2_x branch and for release 2.2.2.GA.

Unit test:  org.jboss.test.remoting.transport.socket.connectionpools.ClearConnectionPoolsTestCase.

> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 20:26:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-783) Remove network i/o
 from synch blocks that establish and terminate LeasePingers
In-Reply-To: <27284519.1185682547092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10670514.1187828778227.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-783?page=all ]

Ron Sigal resolved JBREM-783.
-----------------------------

    Resolution: Won't Fix

This issue was introduced in the process of getting a JBossMessaging stress test to pass: org.jboss.test.messaging.jms.stress.SeveralClientsStressTest.  It turns out that other code and configuration changes were sufficient for that test to pass, so these changes have been backed out.

> Remove network i/o from synch blocks that establish and terminate LeasePingers
> ------------------------------------------------------------------------------
>
>                 Key: JBREM-783
>                 URL: http://jira.jboss.com/jira/browse/JBREM-783
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network i/o in a synchronization block.  The synchronization should be reorganized to avoid 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 lists.jboss.org  Wed Aug 22 20:28:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 20:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <12929149.1187828898297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=all ]

Michael Neale updated JBRULES-1112:
-----------------------------------

    Security: Public  (was: JBoss Customer)

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Mark Proctor
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 20:30:33 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Wed, 22 Aug 2007 20:30:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <15927763.1187829033962.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=all ]

Fernando Meyer reassigned JBRULES-1112:
---------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 20:30:34 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Wed, 22 Aug 2007 20:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <7138848.1187829034117.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373430 ] 
            
Fernando Meyer commented on JBRULES-1112:
-----------------------------------------

There is no bundle for any jboss version in jetty home page http://sourceforge.net/project/showfiles.php?group_id=7322 it points to a empty project page in sourceforge. 
Otherwise I have brms working fine with jetty 6.1.1, Just adding three missing libraries jboss-faces.jar, jsf-api.jar and jsf-impl.jar. 

This guy is editing the JBRMS.jsp and adding unnecessary things as well there is no jboss-faces jar in classpath. probably thats the main reason for that error. But, I can't test because I didn't found the bundle for jboss at jetty page. 

Fernando

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 20:32:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14138954.1187829138241.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-793?page=all ]

Ron Sigal resolved JBREM-793.
-----------------------------

    Resolution: Done

This synchronization was necessary in the context of changes made for JBREM-783 "Remove network i/o from synch blocks that establish and terminate LeasePingers", which introduced a race condition.  Since the changes for JBREM-783 was backed out, the current issue can be dropped.

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Wed Aug 22 20:37:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5705961.1187829438621.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-793?page=all ]

Ron Sigal reopened JBREM-793:
-----------------------------

             

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Wed Aug 22 20:39:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 20:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-793) Lease should
 synchronize access to client map
In-Reply-To: <4351223.1187380741279.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13630427.1187829558219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-793?page=all ]

Ron Sigal resolved JBREM-793.
-----------------------------

    Resolution: Won't Fix

Should have closed with "Won't Fix" resolution instead of "Done".

> Lease should synchronize access to client map
> ---------------------------------------------
>
>                 Key: JBREM-793
>                 URL: http://jira.jboss.com/jira/browse/JBREM-793
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Multiple worker threads can call org.jboss.remoting.Lease.updateLease() and Lease.terminateLease(), which access the Map holding client information.  While running org.jboss.test.remoting.lease.synchronization.MultipleClientSynchronizationTestCase, it was observed that occasionally accessing the Map would return null instead of the correct 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 lists.jboss.org  Wed Aug 22 21:00:29 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 22 Aug 2007 21:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-794)
 LeasePinger.addClient() should
 not create a new LeaseTimerTask if none currently exists
In-Reply-To: <18755133.1187587681051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5611848.1187830829794.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-794?page=comments#action_12373433 ] 
            
Ron Sigal commented on JBREM-794:
---------------------------------

Change applied for release 2.2.2.GA and on branch remoting_2_x.

Unit test:  org.jboss.test.remoting.lease.UniquePingerTaskTestCase.

> LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists
> ---------------------------------------------------------------------------------------
>
>                 Key: JBREM-794
>                 URL: http://jira.jboss.com/jira/browse/JBREM-794
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> When org.jboss.remoting.LeasePinger.addClient() adds a new org.jboss.remoting.Client with a shorter ping period, it restarts the LeaseTimerTask.  However, org.jboss.remoting.MicroRemoteClientInvoker.establishLease() calls LeasePinger.addClient() before it calls LeasePinger.startPing().  LeasePinger incorrectly creates a LeaseTimerTask in addClient() and then creates a second one in startPing().
> LeasePinger.addClient() should be changed so that it starts a new LeaseTimerTask only if one already 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 lists.jboss.org  Wed Aug 22 21:17:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 22 Aug 2007 21:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <5694797.1187831838455.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373435 ] 
            
Michael Neale commented on JBRULES-1112:
----------------------------------------

some of those files have since been removed - they are old and incorrect. If you go to the main url that the app is on, the index.jsp will redirect to the correct URL automatically. 

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Wed Aug 22 21:42:18 2007
From: jira-events at lists.jboss.org (Jose Pedro Pereira (JIRA))
Date: Wed, 22 Aug 2007 21:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-536) Add a
 display-name property
 per portal object that contains a i18n name for displaying object
Message-ID: <1984743.1187833338655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-536?page=comments#action_12373436 ] 
            
Jose Pedro Pereira commented on JBPORTAL-536:
---------------------------------------------

We extended the object_node object on version 2.4 to at least support a display label on each object node. We have also added other properties, such as "open in external window" and "external url", etc... How can we contribute this changes? 

> 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
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 22 21:44:23 2007
From: jira-events at lists.jboss.org (Jose Pedro Pereira (JIRA))
Date: Wed, 22 Aug 2007 21:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-771) introduce page
	inheritance
Message-ID: <13814553.1187833463393.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-771?page=comments#action_12373437 ] 
            
Jose Pedro Pereira commented on JBPORTAL-771:
---------------------------------------------

We have implemented not a solution of page inheritance, but a solution of "page copy", with possible recursion (meaning copy all sub-pages) and portlet windows. What is the best way to contribute this changes?

> introduce page inheritance
> --------------------------
>
>                 Key: JBPORTAL-771
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-771
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Martin Holzner
>
> We have at least one concrete example already that shows the need of such a feature, but I'm sure there are many more. 
> Right now all pages that want to expose the tabed navigation in the top need to add the NavigationPortletWindow in the navigation region. It would make it much easier to create 'templated' pages that contain certain behaviour like the navigation , if we'd allow each page to inherit from another. 
> This would enable the admin to create some useful template pages that all other pages can inherit from, and hence get the same bahaviour. No need to place the same portlet windows on every page anymore.
> We could implement this as
>  * 'real' inheritence that is kept in the PortalObject tree and evealuated in each page request (or each modification to a portal object), or
>  * templating solution, that makes a hard copy into the new page without any future tie back to the 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 lists.jboss.org  Wed Aug 22 21:57:19 2007
From: jira-events at lists.jboss.org (Jose Pedro Pereira (JIRA))
Date: Wed, 22 Aug 2007 21:57:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1647) Integrate Portal
 Login with
 CAS (edu.yale Central Authentication Service) and automate fetching of user
 groups/roles and other information from ldap directory services
Message-ID: <30995864.1187834239145.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate Portal Login with CAS (edu.yale Central Authentication Service) and automate fetching of user groups/roles and other information from ldap directory services
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1647
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1647
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Security
            Reporter: Jose Pedro Pereira
         Assigned To: Julien Viet


We have allready developed this integration... It is not a single and pretty solution, as it dependes on jboss configuration, extension of the embeded tomcat login modules, special login contexts and additional rules classes to gather all the information needed, but we do have such setups... What is the best way to contribute this code and document the required changes to a standard install? Maybe this could be made simpler and more generic... 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 00:24:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 23 Aug 2007 00:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-796) Verify Remoting
 2.2.2 is compatible with earlier versions
Message-ID: <17644775.1187843058201.JavaMail.jira@cloud.prod.atl2.jboss.com>

Verify Remoting 2.2.2 is compatible with earlier versions
---------------------------------------------------------

                 Key: JBREM-796
                 URL: http://jira.jboss.com/jira/browse/JBREM-796
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.2.GA
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.2.GA


Need to add version 2.2.0.SP4 jboss-remoting.jar to src/etc/lib and run tests.versioning.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 lists.jboss.org  Thu Aug 23 00:38:18 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Thu, 23 Aug 2007 00:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-536) Add a
 display-name property
 per portal object that contains a i18n name for displaying object
Message-ID: <11056603.1187843898321.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-536?page=comments#action_12373439 ] 
            
Julien Viet commented on JBPORTAL-536:
--------------------------------------

you need to
provide a patch
create a jira issue targetting the version that patch fixes in
sign up the contributor agreement
attach the patch to the jira issue


> 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
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:09:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 23 Aug 2007 01:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-796) Verify Remoting
 2.2.2 is compatible with earlier versions
In-Reply-To: <17644775.1187843058201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1284591.1187845758238.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-796?page=comments#action_12373441 ] 
            
Ron Sigal commented on JBREM-796:
---------------------------------

Running tests.versioning.all shows that Remoting from branch 2_2_0_GA tagged remoting_2_2_2_Beta (i.e., Remoting 2.2.2.Beta) is compatible with versions:

   2_2_0_SP4
   2_0_0_GA
   1_4_6_GA
   1_4_4_GA
   1_4_3_GA

> Verify Remoting 2.2.2 is compatible with earlier versions
> ---------------------------------------------------------
>
>                 Key: JBREM-796
>                 URL: http://jira.jboss.com/jira/browse/JBREM-796
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> Need to add version 2.2.0.SP4 jboss-remoting.jar to src/etc/lib and run tests.versioning.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 lists.jboss.org  Thu Aug 23 01:21:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1036) TimeOut method
 callback has no security context
Message-ID: <8577170.1187846478268.JavaMail.jira@cloud.prod.atl2.jboss.com>

TimeOut method callback has no security context
-----------------------------------------------

                 Key: EJBTHREE-1036
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1036
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Spec 18.2.2:
"Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity." 


Basically the ejbTimeout callback should have zero security checks (bypass auth, authorization, runas).  This is in line with ejb2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:21:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1036) TimeOut method
 callback should bypass security as it has no security context
In-Reply-To: <8577170.1187846478268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2663576.1187846478380.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1036?page=all ]

Anil Saldhana updated EJBTHREE-1036:
------------------------------------

    Summary: TimeOut method callback should bypass security as it has no security context  (was: TimeOut method callback has no security context)

> TimeOut method callback should bypass security as it has no security context
> ----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1036
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1036
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity." 
> Basically the ejbTimeout callback should have zero security checks (bypass auth, authorization, runas).  This is in line with ejb2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:31:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1027) Timeout method
 gets called with an unspecified caller identity
In-Reply-To: <6643972.1186567051460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11439646.1187847078252.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1027?page=comments#action_12373442 ] 
            
Anil Saldhana commented on EJBTHREE-1027:
-----------------------------------------

Please look at EJBTHREE-1036 which leads to a security bypass due to ejbTimeOut callback having no security context as per spec.  So any call to getCallerPrincipal should return the unauthenticatedIdentity of the security domain that drives the ejb.

EJBTHREE-1036 is done for JBAS5 trunk.


> Timeout method gets called with an unspecified caller identity
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1027
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1027
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: AS 4.2.1.GA
>            Reporter: Carlo de Wolf
>
> Having a secured bean with a timeout method with @PermitAll, but without an unauthenticatedIdentity will lead to a 'random' identity being used to call the method or no identity at all. The last one leads to EJBAccessExceptions.
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity."
> We must disallow all calls to a timeout method if unauthenticatedIdentity is not 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 lists.jboss.org  Thu Aug 23 01:31:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 01:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1036) TimeOut method
 callback should bypass security as it has no security context
In-Reply-To: <8577170.1187846478268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31008277.1187847078385.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1036?page=comments#action_12373443 ] 
            
Anil Saldhana commented on EJBTHREE-1036:
-----------------------------------------

This is complete in JBAS5 Trunk version of EJB3.  Please set the appropriate version and close this issue.

> TimeOut method callback should bypass security as it has no security context
> ----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1036
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1036
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Spec 18.2.2:
> "Since the timeout callback method is an internal method of the bean class, it has no client security context. When getCallerPrincipal is called from within the timeout callback method, it returns the container's representation of the unauthenticated identity." 
> Basically the ejbTimeout callback should have zero security checks (bypass auth, authorization, runas).  This is in line with ejb2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 01:35:29 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 01:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1113) renaming a
 package messes up the assets in it
Message-ID: <18471627.1187847329362.JavaMail.jira@cloud.prod.atl2.jboss.com>

renaming a package messes up the assets in it 
----------------------------------------------

                 Key: JBRULES-1113
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1113
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-brms
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Michael Neale
            Priority: Critical
             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 01:42:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 01:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1037) fix RunAs
 principal propagation
Message-ID: <27581534.1187847738271.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix RunAs principal propagation
-------------------------------

                 Key: EJBTHREE-1037
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1037
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA
            Reporter: William DeCoste
         Assigned To: William DeCoste


We decided it would the principal associated with the run-as identity.
In this case its anonymous unless overridden in the run-as config. This
is what the cts14 tests required. We used to return the original caller
principal, but with the need to assign multiple roles to the run-as
principal for the cts14 tests, we switched this to a separate run-as
principal. The ejb3-spec is a little more clear about there being a
run-as principal:

17.1:
The security principal under which a method invocation is performed is
typically that of the component's caller. By specifying a run-as
identity, however, it is possible to specify that a different principal
be substituted for the execution of the methods of the bean's business
interface, home interface, component interface, and/or web service
endpoint and any methods of other enterprise beans that the bean may
call.
This determines whether the caller principal is propagated from the
caller to the callee?that is, whether the called enterprise bean will
see the same returned value of the EJBContext.getCallerPrincipal
as the calling enterprise bean?or whether a security principal that has
been assigned to the specified security role will be used for the
execution of the bean's methods and will be visible as the
caller principal in the bean's callee.

17.3.4 Specification of Security Identities in the Deployment Descriptor
...
Because the Bean Provider and Application Assembler do not, in general,
know the security environment of the operational environment, the run-as
identity is designated by a logical role-name, which
corresponds to one of the security roles defined by the Bean Provider or
Application Assembler in the metadata annotations or deployment descriptor.
The Deployer then assigns a security principal defined in the
operational environment to be used as the principal for the run-as
identity. The security principal assigned by the Deployer should be a
principal that has been assigned to the security role specified by RunAs
annotation or by the role-name element of the run-as deployment
descriptor element.
The Bean Provider and/or Application Assembler is responsible for the
following in the specification of run-as identities:
? Use the RunAs metadata annotation or role-name element of the run-as
deployment descriptor element to define the name of the security role.
? Optionally, use the description element to provide a description of
the principal that is expected to be bound to the run-as identity in
terms of its security role.

17.4.3 Principal Delegation
The Deployer is responsible for configuring the principal delegation for
inter-component calls. The Deployer must follow any instructions
supplied by the Bean Provider and/or Application Assembler
(for example, provided in the RunAs metadata annotations, the run-as
elements of the deployment descriptor, in the description elements of
the annotations or deployment descriptor, or in a deployment manual).
If the security identity is defaulted, or it is explicitly specified
that the caller identity be used (e.g., use-caller-identity deployment
descriptor element is specified), the caller principal is propagated
from one component to another (i.e., the caller principal of the first
enterprise bean in a call-chain is passed to the enterprise beans down
the chain).
If the Bean Provider or Application Assembler specifies that a run-as
identity be used on behalf of a particular enterprise bean, the Deployer
must configure the enterprise beans such that the run-as principal is
used as the caller principal on any calls that the enterprise bean makes
to other beans, and that the run-as principal is propagated along the
call-chain of those other beans (in the absence of the specification of
any further run-as elements).

Anil Saldhana wrote:
> > Scott,
> >   Bill Decoste and I have a simple difference in understanding of
> > RunAsIdentity in relation to getCallerPrincipal
> > 
> > BeanA ->  BeanB
> > 
> > BeanA defines a RunAs annotation with a role.  No principal is attached
> > to this annotation (so we will take anonymous as the principal).
> > 
> > If a Principal  "anil"  invoked BeanA.  Then a method in BeanA called a
> > method in BeanB.
> > 
> > If BeanB does a getCallerPrincipal,  does it return "anonymous" that is
> > attached to run-as or it will return "Somebody"?   I am saying
> > "anonymous" and BillD says it is "anil".
> > 
> > My understanding is that RunAs does a security context switch and a
> > security-identity in ejb-jar.xml with <use-caller-identity> would
> > propogate.
> > 
> > Can you clarify, please?
> > 
> > Regards,
> > Anil
> > 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Thu Aug 23 01:55:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 01:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1113) renaming a package
 messes up the assets in it
In-Reply-To: <18471627.1187847329362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25530711.1187848518207.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1113?page=all ]

Michael Neale closed JBRULES-1113.
----------------------------------

    Resolution: Done

> renaming a package messes up the assets in it 
> ----------------------------------------------
>
>                 Key: JBRULES-1113
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1113
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>            Priority: Critical
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 02:01:30 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 02:01:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1113) renaming a
 package messes up the assets in it
In-Reply-To: <18471627.1187847329362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27797085.1187848890365.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1113?page=comments#action_12373444 ] 
            
Michael Neale commented on JBRULES-1113:
----------------------------------------

was due to not renaming the package name in the assets - this is necessary as each asset keeps a copy of the package name (needed for versioning -bloody versioning, as always).

> renaming a package messes up the assets in it 
> ----------------------------------------------
>
>                 Key: JBRULES-1113
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1113
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>            Priority: Critical
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 03:38:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 23 Aug 2007 03:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1020) BRMS Custom Rule
 Selector for Creating Deployable Packages
In-Reply-To: <17429031.1184893607367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10669828.1187854698320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1020?page=all ]

Michael Neale closed JBRULES-1020.
----------------------------------

    Resolution: Done

done for 4.0.1 allowing custom selectors (either a drl or a class implementation can be configured by a sys admin).

> BRMS Custom Rule Selector for Creating Deployable Packages
> ----------------------------------------------------------
>
>                 Key: JBRULES-1020
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1020
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: general
>            Reporter: Barry Knapp
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> Use Case : Ability to include or exclude rules in a deployable package based on rule meta data or custom rule attributes.
> Add an extension point to the BRMS for deciding which rules should be included in a deployable package.  
> A CustomSelector interface with an boolean accepts(Rule) method would allow implementors to create a class and implement the accepts method.  The custom method could then analyze the rule to determine if the rule should be included in the package being generated by return true for inclusion.  A property file with CustomExtractor=com...implementing class would allow the implementor to inject their CustomSelector 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 lists.jboss.org  Thu Aug 23 03:40:45 2007
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 23 Aug 2007 03:40:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4567) Install
	jbossws-2.0.1.GA
In-Reply-To: <13626450.1184838707453.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7413998.1187854845633.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4567?page=comments#action_12373455 ] 
            
Thomas Diesler commented on JBAS-4567:
--------------------------------------

The target for Beta3 is 2.0.x

> Install jbossws-2.0.1.GA
> ------------------------
>
>                 Key: JBAS-4567
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4567
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 04:52:18 2007
From: jira-events at lists.jboss.org (Alexandre Russel (JIRA))
Date: Thu, 23 Aug 2007 04:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1011) Component to
 calculate the memory footprint of elements in the cache
In-Reply-To: <17611450.1174489728864.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7684305.1187859138239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1011?page=comments#action_12373459 ] 
            
Alexandre Russel commented on JBCACHE-1011:
-------------------------------------------

do you have any info on: "Java5 java offers support for determining the size of objects"

AFAIK, java 5 only allows to know memory usage and send notification when a threshold is exceeded
on pools that supports it.
Calculating memory usage before and after object allocation would give a wrong size of objects and
 would be unusable in J2EE. Especially because if I put a List in the cache and add object to the list I 
would need to know the total size of list + objects, so I need to trace each object allocation.

I think this issue should closed as long as knowing the size of objects is not accurate.
alex



> Component to calculate the memory footprint of elements in the cache
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-1011
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1011
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Mircea Markus
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>
> As with Java5 java offers support for determining the size of objects. An memory based eviction policy can be written for this java version only. The basic idea is to let the user to specify the amount of memory he wants to 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 lists.jboss.org  Thu Aug 23 06:19:19 2007
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 23 Aug 2007 06:19:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27361487.1187864359007.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-89?page=comments#action_12373464 ] 
            
Jean-Frederic Clere commented on JBWEB-89:
------------------------------------------

To reproduce it just configure a cluster with jvmRoute of different length. Send a request to the one has the small jvmRoute and failover to the one with long jvmRoute for the next request.

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Jean-Frederic Clere
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:05:22 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 23 Aug 2007 07:05:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAOP-200) Make sure the batch
 and sh files work
Message-ID: <15610964.1187867122589.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-200?page=all ]

Stale Pedersen resolved JBAOP-200.
----------------------------------

    Resolution: Done

confirmed that the fixes works on both linux and windows.

> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:05:22 2007
From: jira-events at lists.jboss.org (Stale Pedersen (JIRA))
Date: Thu, 23 Aug 2007 07:05:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-200) Make sure the batch
 and sh files work
Message-ID: <19983135.1187867122900.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-200?page=all ]

Stale Pedersen closed JBAOP-200.
--------------------------------


> Make sure the batch and sh files work
> -------------------------------------
>
>                 Key: JBAOP-200
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-200
>             Project: JBoss AOP
>          Issue Type: Bug
>            Reporter: Kabir Khan
>         Assigned To: Stale Pedersen
>             Fix For: 2.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:36:18 2007
From: jira-events at lists.jboss.org (Dean Jones (JIRA))
Date: Thu, 23 Aug 2007 07:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1114) Rule compilation
 not thread-safe
Message-ID: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule compilation not thread-safe
--------------------------------

                 Key: JBRULES-1114
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Dean Jones
         Assigned To: Mark Proctor


Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.

See http://thread.gmane.org/gmane.comp.java.drools.user/7834


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 07:42:18 2007
From: jira-events at lists.jboss.org (Dean Jones (JIRA))
Date: Thu, 23 Aug 2007 07:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1114) Rule compilation
 not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24664839.1187869338282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1114?page=all ]

Dean Jones updated JBRULES-1114:
--------------------------------

    Attachment: PackageBuilderThreadSafetyTest.java

Adding a test case. Note that this is not guaranteed to fail, but is pretty likely to fail.


> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Mark Proctor
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 08:49:34 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 08:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
Message-ID: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>

Undeploying a portlet in an exploded form causes a NullPointerException
-----------------------------------------------------------------------

                 Key: JBPORTAL-1648
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final
         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
            Reporter: Martin Putz


The process to reproduce the issue :
1- start jboss as
2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
4- remove the portlet directory (helloworldportalpage.war from deploy/)
5- go to the 'MyPage' page, you should see the NullPointerException:

java.lang.NullPointerException
at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
...


Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 08:49:34 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 08:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11611212.1187873374627.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1648?page=all ]

Martin Putz updated JBPORTAL-1648:
----------------------------------

    Help Desk Ticket Reference: https://na1.salesforce.com/50030000003QWf4

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 08:51:18 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 08:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12028900.1187873478274.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1648?page=all ]

Martin Putz updated JBPORTAL-1648:
----------------------------------

    Help Desk Ticket Reference:   (was: https://na1.salesforce.com/50030000003QWf4)

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:30:18 2007
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 23 Aug 2007 09:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBWEB-89) Getting exception
 org.apache.commons.httpclient.HttpRecoverableException
In-Reply-To: <13131444.1186741801176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28242080.1187875818913.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-89?page=all ]

Jean-Frederic Clere resolved JBWEB-89.
--------------------------------------

    Resolution: Done

I have fixed the branches 4.2.x and 4.0.x trunk is ok the logic is different there.

> Getting exception org.apache.commons.httpclient.HttpRecoverableException
> ------------------------------------------------------------------------
>
>                 Key: JBWEB-89
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-89
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Apache 2.0.52-32/mod_jk 1.2.22/JBoss 4.2.0.GA
>            Reporter: Masao Kato
>         Assigned To: Jean-Frederic Clere
>         Attachments: patch.txt
>
>
> We are getting this exception .
> ERROR [org.apache.catalina.connector.CoyoteAdapter] 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 32
>         at java.lang.String.substring(String.java:1765)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:128)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
>         at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
>         at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)
>         
> I watched a source file(JvmRouteValve.java). I think that substring of the session ID may be wrong. 
> I made a patch. 
> Is this right?
> --- src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java.orig       2007-08-10 18:59:45.000000000 +0900
> +++ src/main/org/jboss/web/tomcat/service/session/JvmRouteValve.java    2007-08-10 19:01:11.000000000 +0900
> @@ -125,7 +125,7 @@
>        int index = oldsessionId.lastIndexOf(".");
>        if (index > 0)
>        {
> -         receivedJvmRoute = oldsessionId.substring(index + 1, sessionId.length());
> +         receivedJvmRoute = oldsessionId.substring(index + 1, oldsessionId.length());
>        }
>        String requestedJvmRoute = null;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:32:18 2007
From: jira-events at lists.jboss.org (Anthony Dawson (JIRA))
Date: Thu, 23 Aug 2007 09:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1115) Modifications to
 list objects
 contained within a bean and carried out during the execution of a rule are
 not reflected in the original list i.e. the changes are lost  between the
 instance available within the rule  and that of the original bean
Message-ID: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1115
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
         Environment: HP-UX  java version "1.5.0.05"

            Reporter: Anthony Dawson
         Assigned To: Mark Proctor


Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean

During the execution of the rules when I modify a list my changes are not reflected in my bean. 
Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.

Details of this problem are described in the forum messages.

http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:40:18 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 23 Aug 2007 09:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4624) Parse Role Name from
	Role DN
Message-ID: <10860214.1187876418658.JavaMail.jira@cloud.prod.atl2.jboss.com>

Parse Role Name from Role DN
----------------------------

                 Key: JBAS-4624
                 URL: http://jira.jboss.com/jira/browse/JBAS-4624
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Mike Millson
         Assigned To: Anil Saldhana


Improve the performance of the LdapExtLoginModule by adding a parseRoleNameFromDN option or check the returned DN to see if it already includes the roleNameAttributeID, and if it does, parse the roleNameAttributeID from the DN rather than querying LDAP for the roleNameAttributeID.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:42:19 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 23 Aug 2007 09:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4625) Connection leak if
 failure to setup connection in jms inbound resource adapter
Message-ID: <4162579.1187876539379.JavaMail.jira@cloud.prod.atl2.jboss.com>

Connection leak if failure to setup connection in jms inbound resource adapter
------------------------------------------------------------------------------

                 Key: JBAS-4625
                 URL: http://jira.jboss.com/jira/browse/JBAS-4625
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


The jms inbound resource adapter is leaking connections if there is an error
setting up the connection.

In pseudo code in setup[Queue|Topic]Connection
{
      ...
+      try
+      {
         if (clientID != null)
            result.setClientID(clientID);
         result.setExceptionListener(this);
         log.debug("Using topic connection " + result);
         return result;
+     }
+     catch (Throwable t)
+     {
+        result.close();
+        throw 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 lists.jboss.org  Thu Aug 23 09:44:34 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 23 Aug 2007 09:44:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4624) Parse Role Name from
	Role DN
In-Reply-To: <10860214.1187876418658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3376222.1187876674920.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4624?page=all ]

Mike Millson closed JBAS-4624.
------------------------------

    Resolution: Duplicate Issue

This should have been created as an ASPATCH.

> Parse Role Name from Role DN
> ----------------------------
>
>                 Key: JBAS-4624
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4624
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>
> Improve the performance of the LdapExtLoginModule by adding a parseRoleNameFromDN option or check the returned DN to see if it already includes the roleNameAttributeID, and if it does, parse the roleNameAttributeID from the DN rather than querying LDAP for the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:48:18 2007
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Thu, 23 Aug 2007 09:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19502509.1187876898321.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1648?page=all ]

Martin Putz updated JBPORTAL-1648:
----------------------------------

    Attachment: patch.txt

attached a patch for org.jboss.portal.server.deployment.jboss.Deployment

On exploded deployments, the URL to the /WEB-INF folder of a web app was missing the trailing slash. With this corrupted path information, the undeployment procedure failed to find the corresponding entry in the MainDeployer's map of deployed elements. As a result, the contents of the /WEB-INF folder were not undeployed completely.

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>         Attachments: patch.txt
>
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:54:18 2007
From: jira-events at lists.jboss.org (Dean Jones (JIRA))
Date: Thu, 23 Aug 2007 09:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
Message-ID: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>

"not" doesn't work for StatelessSessions
----------------------------------------

                 Key: JBRULES-1116
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Dean Jones
         Assigned To: Mark Proctor
            Priority: Blocker


When using a StatelessSession, the "not" quantifier doesn't work. Test case below.

package org.drools.examples

rule "Hello World"
       when
           Integer()
       then
           System.out.println("Hello world");
end

rule "Goodbye World"
       when
           not Integer()
       then
           System.out.println("Goodbye cruel world");
end

public class TestReadRuleFile {

 public static void main(String[] args) throws Exception {
  PackageBuilder builder = new PackageBuilder();
  InputStreamReader is = new InputStreamReader(
   TestReadRuleFile.class.getResourceAsStream("test.drl"));
  builder.addPackageFromDrl(is);
  Package pkg = builder.getPackage();
  RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
  jbossRulebase.addPackage(pkg);
  StatelessSession session = jbossRulebase.newStatelessSession();
  session.execute(new Float(1));
 }

}

The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 09:59:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 23 Aug 2007 09:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4625) Connection leak if
 failure to setup connection in jms inbound resource adapter
In-Reply-To: <4162579.1187876539379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5761504.1187877558291.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4625?page=all ]

Adrian Brock closed JBAS-4625.
------------------------------

    Resolution: Done

> Connection leak if failure to setup connection in jms inbound resource adapter
> ------------------------------------------------------------------------------
>
>                 Key: JBAS-4625
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4625
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> The jms inbound resource adapter is leaking connections if there is an error
> setting up the connection.
> In pseudo code in setup[Queue|Topic]Connection
> {
>       ...
> +      try
> +      {
>          if (clientID != null)
>             result.setClientID(clientID);
>          result.setExceptionListener(this);
>          log.debug("Using topic connection " + result);
>          return result;
> +     }
> +     catch (Throwable t)
> +     {
> +        result.close();
> +        throw 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 lists.jboss.org  Thu Aug 23 10:18:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1168) Sometimes aquired
 locks are not released
Message-ID: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>

Sometimes aquired locks are not released
----------------------------------------

                 Key: JBCACHE-1168
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
    Affects Versions: 1.4.1.SP4
         Environment: Windows XP, jrockit90_150_06 
Solaris 10
            Reporter: Jacek Halat
         Assigned To: Jason T. Greene
         Attachments: TransactionStormTest.java

Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
Main loop:
		while (true) {
			for (int x = 0; x < 2; x++) {
				WorkThread t = new WorkThread(x == 1);
				threads.add(t);
				t.start();
			}
			for (WorkThread separateThread : threads) {
				separateThread.join();
				if (separateThread.getException() != null) {
					//separateThread.getException().getMessage();
				}
			}
			int locksNum = getNumberOfLocksHeld();
//			System.out.println("Locks="+locksNum);
			// checkpoint
			if (cache.getNumberOfLocksHeld()>0){
				System.out.println("ERROR, locks="+locksNum);
				doDomethingOnCache(1);
			}
			assertEquals(0, locksNum);
		}


Exception - after //checkpoint line numberOfLocks is grater than 0!

JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 10:18:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1168) Sometimes aquired
 locks are not released
In-Reply-To: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10277241.1187878698837.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1168?page=all ]

Jacek Halat updated JBCACHE-1168:
---------------------------------

    Attachment: TransactionStormTest.java

Test to this issue.

> Sometimes aquired locks are not released
> ----------------------------------------
>
>                 Key: JBCACHE-1168
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, jrockit90_150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: TransactionStormTest.java
>
>
> Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
> Main loop:
> 		while (true) {
> 			for (int x = 0; x < 2; x++) {
> 				WorkThread t = new WorkThread(x == 1);
> 				threads.add(t);
> 				t.start();
> 			}
> 			for (WorkThread separateThread : threads) {
> 				separateThread.join();
> 				if (separateThread.getException() != null) {
> 					//separateThread.getException().getMessage();
> 				}
> 			}
> 			int locksNum = getNumberOfLocksHeld();
> //			System.out.println("Locks="+locksNum);
> 			// checkpoint
> 			if (cache.getNumberOfLocksHeld()>0){
> 				System.out.println("ERROR, locks="+locksNum);
> 				doDomethingOnCache(1);
> 			}
> 			assertEquals(0, locksNum);
> 		}
> Exception - after //checkpoint line numberOfLocks is grater than 0!
> JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 10:20:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1168) Sometimes aquired
 locks are not released
In-Reply-To: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19652375.1187878818389.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1168?page=all ]

Jacek Halat updated JBCACHE-1168:
---------------------------------

    Attachment: output.txt

Example console output with error

> Sometimes aquired locks are not released
> ----------------------------------------
>
>                 Key: JBCACHE-1168
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, jrockit90_150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: output.txt, TransactionStormTest.java
>
>
> Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
> Main loop:
> 		while (true) {
> 			for (int x = 0; x < 2; x++) {
> 				WorkThread t = new WorkThread(x == 1);
> 				threads.add(t);
> 				t.start();
> 			}
> 			for (WorkThread separateThread : threads) {
> 				separateThread.join();
> 				if (separateThread.getException() != null) {
> 					//separateThread.getException().getMessage();
> 				}
> 			}
> 			int locksNum = getNumberOfLocksHeld();
> //			System.out.println("Locks="+locksNum);
> 			// checkpoint
> 			if (cache.getNumberOfLocksHeld()>0){
> 				System.out.println("ERROR, locks="+locksNum);
> 				doDomethingOnCache(1);
> 			}
> 			assertEquals(0, locksNum);
> 		}
> Exception - after //checkpoint line numberOfLocks is grater than 0!
> JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 10:57:18 2007
From: jira-events at lists.jboss.org (Jacek Halat (JIRA))
Date: Thu, 23 Aug 2007 10:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1168) Sometimes aquired
 locks are not released
In-Reply-To: <30832886.1187878698592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22612498.1187881039013.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1168?page=all ]

Jacek Halat updated JBCACHE-1168:
---------------------------------

    Attachment: jbosscache.log

Logs from TreeCache (in DEBUG mode).
Important fragment:
After every rollback logs contains:
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/d, marked for removal.
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/c, marked for removal.
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/b, marked for removal.
2007-08-23 16:46:32,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:32,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/a, marked for removal. 


but in one case:
2007-08-23 16:46:33,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:33,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/d, marked for removal.
2007-08-23 16:46:33,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:33,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/c, marked for removal.
2007-08-23 16:46:33,609 DEBUG [TreeCache] This remove call is triggered by a transaction rollback, as a compensation operation.  Do a realRemove() instead.
2007-08-23 16:46:33,609 DEBUG [TreeCache] Performing a real remove for node /a/b/c/b, marked for removal. 

Where is entry for /a/b/c/a node? 
>From now /a/b/c/a is locked forever.

> Sometimes aquired locks are not released
> ----------------------------------------
>
>                 Key: JBCACHE-1168
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1168
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.1.SP4
>         Environment: Windows XP, jrockit90_150_06 
> Solaris 10
>            Reporter: Jacek Halat
>         Assigned To: Jason T. Greene
>         Attachments: jbosscache.log, output.txt, TransactionStormTest.java
>
>
> Sometimes under heavy load acquired locks are not released - node is locked forever. Only what can we do is stop/start cache.
> Main loop:
> 		while (true) {
> 			for (int x = 0; x < 2; x++) {
> 				WorkThread t = new WorkThread(x == 1);
> 				threads.add(t);
> 				t.start();
> 			}
> 			for (WorkThread separateThread : threads) {
> 				separateThread.join();
> 				if (separateThread.getException() != null) {
> 					//separateThread.getException().getMessage();
> 				}
> 			}
> 			int locksNum = getNumberOfLocksHeld();
> //			System.out.println("Locks="+locksNum);
> 			// checkpoint
> 			if (cache.getNumberOfLocksHeld()>0){
> 				System.out.println("ERROR, locks="+locksNum);
> 				doDomethingOnCache(1);
> 			}
> 			assertEquals(0, locksNum);
> 		}
> Exception - after //checkpoint line numberOfLocks is grater than 0!
> JUnit is provided to this issue, but this error is nondeterministic - sometimes fails after 5 seconds and another time after 20 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 lists.jboss.org  Thu Aug 23 11:27:18 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Aug 2007 11:27:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1052) When running
 stress tests wrong log4j.xml is picked up
Message-ID: <10580807.1187882838240.JavaMail.jira@cloud.prod.atl2.jboss.com>

When running stress tests wrong log4j.xml is picked up
------------------------------------------------------

                 Key: JBMESSAGING-1052
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1052
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.4.0.CR2


When running stress tests, the log4j.xml from tests/etc, but the log4j.xml from tests/etc/stress isn't being used.

This means stress tests are being run on trace logging, which is incorrect (makes them take ages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:41:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18695620.1187883678474.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1116?page=all ]

Edson Tirelli updated JBRULES-1116:
-----------------------------------

      Component/s: Drl Parser/Builder
                   Reteoo
    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:43:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1115) Modifications to
 list objects
 contained within a bean and carried out during the execution of a rule are
 not reflected in the original list i.e. the changes are lost  between the
 instance available within the rule  and that of the original bean
In-Reply-To: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7245682.1187883798332.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1115?page=all ]

Edson Tirelli updated JBRULES-1115:
-----------------------------------

      Component/s: Reteoo
                       (was: Drl Parser/Builder)
    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1115
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: HP-UX  java version "1.5.0.05"
>            Reporter: Anthony Dawson
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> During the execution of the rules when I modify a list my changes are not reflected in my bean. 
> Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.
> Details of this problem are described in the forum messages.
> http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:43:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1114) Rule compilation
 not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33326527.1187883798493.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1114?page=all ]

Edson Tirelli updated JBRULES-1114:
-----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:45:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22238769.1187883918464.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=all ]

Edson Tirelli updated JBRULES-1091:
-----------------------------------

    Component/s: Reteoo

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Thu Aug 23 11:45:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24361259.1187883918685.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=all ]

Edson Tirelli updated JBRULES-1111:
-----------------------------------

      Component/s: Reteoo
    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:45:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1110) Rules with 'From'
 condition with another not using From causes problem
In-Reply-To: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15561331.1187883918882.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1110?page=all ]

Edson Tirelli updated JBRULES-1110:
-----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Edson Tirelli  (was: Mark Proctor)

> Rules with 'From' condition with another not using From causes problem
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1110
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Decision tables
>    Affects Versions:  4.0.0.GA
>         Environment: Any
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Test case:
> Write a Rule that uses a From clause and on another object does not use a from clause:
> example:
> #From row number: 28
> rule "Rules_28"
> 	
> 	when
> 		cntct: Contact(initialized==true)
> 		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
> 		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
> 	then
>                              System.out.println("Fired 28");
> end
> If All 3 are true:
>  1. Delete Condition 2 --> Rule fires
>  2. Delete COnditon 3 (But keep 2) --> Rule fires
>  3. Keep 2 & 3 (with 1) --> Rule does not fire
> Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.
> Please see if it is 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 lists.jboss.org  Thu Aug 23 11:47:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1105) web.xml does not
 conform web-app_2_3.dtd
In-Reply-To: <3916092.1187585177133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19161929.1187884038599.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1105?page=all ]

Edson Tirelli updated JBRULES-1105:
-----------------------------------

    Fix Version/s: 4.0.1
                       (was:  4.0.0.GA)
         Assignee: Fernando Meyer  (was: Mark Proctor)

> web.xml does not conform web-app_2_3.dtd
> ----------------------------------------
>
>                 Key: JBRULES-1105
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1105
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Glassfish
>            Reporter: Michael Max
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> web.xml does not comply with a http://java.sun.com/dtd/web-app_2_3.dtd specification. Because of that drools-jbrms.war cannot be deployed to the servers with a strict validation as Glassfish, just to JBoss AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:47:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1104) Inserted Objects
 are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7526969.1187884038750.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1104?page=all ]

Edson Tirelli updated JBRULES-1104:
-----------------------------------

    Assignee: Mark Proctor  (was: Edson Tirelli)

> Inserted Objects are lost if no matching ObjectTypeNodes
> --------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:49:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1095) Deserializing
 Package Objects Consumes Large Amount of Memory
In-Reply-To: <17599698.1187293445172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24436120.1187884158436.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1095?page=all ]

Edson Tirelli updated JBRULES-1095:
-----------------------------------

    Fix Version/s: FUTURE

> Deserializing Package Objects Consumes Large Amount of Memory
> -------------------------------------------------------------
>
>                 Key: JBRULES-1095
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1095
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Windows
>            Reporter: Ming Jin
>         Assigned To: Mark Proctor
>             Fix For: FUTURE
>
>         Attachments: testdrools.zip
>
>
> Deserializing the Package objects from storage to memory consumes large amount of memory.  My tests showed that for a serialized size of 1MB, 18MB of memory would be consumed during deserialization, mostly from the method org.drools.rule.Package.readExternal.  A test program with resulting profile data would be uploaded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:49:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1048) Context assist is
 not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3882892.1187884158641.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1048?page=all ]

Edson Tirelli updated JBRULES-1048:
-----------------------------------

    Component/s: Eclipse IDE

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Thu Aug 23 11:51:26 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:51:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29333839.1187884286720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-992?page=all ]

Edson Tirelli updated JBRULES-992:
----------------------------------

    Fix Version/s: 4.0.1

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Thu Aug 23 11:53:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:53:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1063) Failing location
 determination tests
In-Reply-To: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22114808.1187884399044.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1063?page=all ]

Edson Tirelli updated JBRULES-1063:
-----------------------------------

      Component/s: Drl Parser/Builder
    Fix Version/s: 4.0.1
                       (was: FUTURE)
         Assignee: Edson Tirelli  (was: Mark Proctor)

Please, in such cases, let the tests break the build and point them to me.

> Failing location determination tests
> ------------------------------------
>
>                 Key: JBRULES-1063
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  
> Their name is prefixed with FAILING
> I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
> The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 11:55:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 11:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1013) Two functions
 with Janino compiler end up with out of memory error
In-Reply-To: <13997820.1184691167170.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9923707.1187884518693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1013?page=all ]

Edson Tirelli updated JBRULES-1013:
-----------------------------------

          Component/s: Drl Parser/Builder
        Fix Version/s: FUTURE
                           (was: 4.0.1)
    Affects Version/s:  4.0.0.GA

> Two functions with Janino compiler end up with out of memory error
> ------------------------------------------------------------------
>
>                 Key: JBRULES-1013
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1013
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>         Environment: Ubuntu Feisty, JDK 1.4 or 1.5, Drools Snapshot
>            Reporter: Pierre Paysant-Le Roux
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> Compiling a simple rules file containing two functions with janino causes an out of memory error.
> Rules file example :
> package test
> function boolean func1() {
> 	return true;
> }
> function boolean func2() {
> 	return true;
> }
> rule "test"
> when
> 	Object()
> then
> 	System.out.println("fired");
> end
> and the code that generate the error :
> package test;
> import java.io.IOException;
> import java.io.InputStreamReader;
> import java.util.Properties;
> import org.drools.compiler.DroolsParserException;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.PackageBuilderConfiguration;
> public class Test {
>     public static void main (String[] args) {
>         Properties properties = new Properties();
>         properties.setProperty("drools.dialect.java.compiler", 
>                                "JANINO");
>         PackageBuilderConfiguration pkgBuilderCfg = new PackageBuilderConfiguration(properties);
>         PackageBuilder builder = new PackageBuilder(pkgBuilderCfg);
>         try {
>             builder.addPackageFromDrl(getSource());
>         } catch (DroolsParserException e) {
>             e.printStackTrace();
>         } catch (IOException e) {
>             e.printStackTrace();
>         }
>     }
>     
>     private static InputStreamReader getSource() {
>         return new InputStreamReader(Test.class.getResourceAsStream( "Sample.drl" ));
>     }
> }
> After profiling, I identified that the problematic line is the 146 one in class JaninoJavaCompiler. It causes the loadIClass method to loop with a cycle that I don't understand. Placing a breakpoint on the line 91 of JaninoJavaCompiler class permit to observe the loop iterations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 12:05:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 12:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31157743.1187885118321.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=all ]

Edson Tirelli resolved JBRULES-1111.
------------------------------------

    Resolution: Won't Fix

That happens because the engine needs to create shadow facts for objects asserted as facts and shadow facts are implemented as lazy proxies. If the class or the methods are final, the engine can't override them. 

So, we strongly discourage you to use final classes or methods as facts, specially if those methods are property accessors.

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 12:19:33 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Aug 2007 12:19:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-404) Create project
 site for jboss-deploy plugin.
In-Reply-To: <27716106.1187728638760.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7798958.1187885973864.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-404?page=all ]

Paul Gier reassigned JBBUILD-404:
---------------------------------

    Assignee: Paul Gier

> Create project site for jboss-deploy plugin.
> --------------------------------------------
>
>                 Key: JBBUILD-404
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-404
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: maven-jboss-deploy-plugin
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> There should be a project site that contains documentation for the plugin on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 12:32:18 2007
From: jira-events at lists.jboss.org (Felipe Piccolini (JIRA))
Date: Thu, 23 Aug 2007 12:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1117) DSL support for
 multiple mvel comparasions (like || ==) in several lines.
Message-ID: <29756989.1187886738288.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL support for multiple mvel comparasions (like || ==) in several lines.
-------------------------------------------------------------------------

                 Key: JBRULES-1117
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1117
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder, Eclipse IDE
    Affects Versions:  4.0.0.GA
         Environment: DSL editor and eclipse IDE.
            Reporter: Felipe Piccolini
         Assigned To: Mark Proctor
             Fix For: FUTURE


It whould be nice if DSL supports multiple lines for multiple comparison (mvel expression) against the same attribute.
Like this:
   DLS: 
       A Person
          - having age equals to 10
          - or equals to 15
          - or greather than 20

  DRL:
     p: Person( age == 10
                || == 15
                || > 20)

Right now, the " - <expression>"  put a 'comma' at the end of the line making this:
     p: Person( age == 10, || == 15, || > 20)

What throws errors...

  Is it possible to do that? I love the || == <value> thing in each line...

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 lists.jboss.org  Thu Aug 23 12:49:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 12:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
In-Reply-To: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13400960.1187887758836.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4623?page=all ]

Brian Stansberry reassigned JBAS-4623:
--------------------------------------

    Assignee: Brian Stansberry  (was: Remy Maucherat)

> org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4623
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: William DeCoste
>         Assigned To: Brian Stansberry
>
> MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().
> Let me know if you see what I mean - I can fix it. 
> I'm looking in Branch_4_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 lists.jboss.org  Thu Aug 23 12:58:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 12:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
In-Reply-To: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17064610.1187888298335.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4623?page=comments#action_12373552 ] 
            
Brian Stansberry commented on JBAS-4623:
----------------------------------------

This class is not meant to be used inside JBoss AS; it's for use in standalone Tomcat.  It's also largely untested in that usage since I wrote it as a community contribution 2 1/2 years ago (i.e. before I joined JBoss/Red Hat).

A hacky fix to this hacky usage would be to only call MBeanServerLocator.setJBoss(getMBeanServer()) if MBeanServerLocator.locateJBoss() returns null. A better fix would be to figure out how to ensure no classes in the package need to find the proper mbean server in this way; they just have it injected or get it from their Container or something.

> org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4623
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: William DeCoste
>         Assigned To: Brian Stansberry
>
> MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().
> Let me know if you see what I mean - I can fix it. 
> I'm looking in Branch_4_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 lists.jboss.org  Thu Aug 23 13:12:18 2007
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Thu, 23 Aug 2007 13:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1091)
 NullPointerException when
 the 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22203962.1187889138397.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=comments#action_12373555 ] 
            
Alexandre Gattiker commented on JBRULES-1091:
---------------------------------------------

Thanks for the tip on accumulate functions. Indeed that is what I developed in my case, though it doesn't help on the null issue of course.

I agree with your assumption, as I understand that Drools cannot handle null facts. There is not always a direct null object available, however (such as your example with Money(0), which lacks a currency). We can still use either the Null Object pattern or a mutable object (commons-lang), something like

MutableObject(value: $totalPayments:) 
   from accumulate( Payment ( customer == $c, $val : value )
                                   init( MutableObject total = new MutableObject(); )
                                   action( total.setValue(addNullSafe( $val, total.getValue()) ); )
                                   result( total ) ) 

So the bug can only be solved in catching the error early and provide a meaningful error message.

Thank you very much for your tips. Drools is so elegant it's highly addictive :)

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Thu Aug 23 14:07:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <13608425.1187892438431.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373559 ] 
            
Fernando Meyer commented on JBRULES-1112:
-----------------------------------------

Wailting for user feedback

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Thu Aug 23 14:07:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1118) Add support for
 rf, xml and dsrl into drools-ant task
Message-ID: <3609578.1187892438576.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for rf, xml and dsrl into drools-ant task 
------------------------------------------------------

                 Key: JBRULES-1118
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1118
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.1
            Reporter: Fernando Meyer
         Assigned To: Fernando Meyer


Add support for rf, xml and dsrl into drools-ant 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 lists.jboss.org  Thu Aug 23 14:11:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1028) importing .brxml
 into the application
In-Reply-To: <30338039.1185367127222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16173322.1187892678449.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1028?page=all ]

Fernando Meyer closed JBRULES-1028.
-----------------------------------

    Resolution: Done

Now you can use drools-ant to compile brxml and other formats into one serialized rulebase 

> importing .brxml into the application
> -------------------------------------
>
>                 Key: JBRULES-1028
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1028
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: windows Xp Proffessional, Java/Eclipse IDE
>            Reporter: sreeni sabapathy
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> The new feature in Jboss rule 4.0, the " New guided drl editor". 
> This feature which works similar to the drools-jbrms in the Eclipse plugin.
> I am able to create the necessatry rules, but as the edited rules exist in "rule.brxml" and in "rule.package". 
> How to Import this ".brxml" and ".package" into the package builder in order to get the package into the Rulebase and get working?
> I tried using the XmlPackageReader.read(reader) and then tried to build through the PackageBuilder . In other case also used the adddrlfomxml().
> It failed in both the case stating it as the 
> "<rule> has an invalid parent element [null]
> 	at org.drools.xml.XmlPackageReader.validate(XmlPackageReader.java:486)
> 	at org.drools.xml.XmlPackageReader.startElement(XmlPackageReader.java:394)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(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.DTDConfiguration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at javax.xml.parsers.SAXParser.parse(Unknown Source)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:321)
> 	at org.drools.xml.XmlPackageReader.read(XmlPackageReader.java:247)
> 	at com.sample.DroolsTest.readRule(DroolsTest.java:60)
> 	at com.sample.DroolsTest.main(DroolsTest.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 lists.jboss.org  Thu Aug 23 14:23:18 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Aug 2007 14:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1033) Rationalise
 and speedup test suite
In-Reply-To: <9387617.1186598269311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13668335.1187893398218.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1033?page=all ]

Tim Fox closed JBMESSAGING-1033.
--------------------------------

    Resolution: Done

> Rationalise and speedup test suite
> ----------------------------------
>
>                 Key: JBMESSAGING-1033
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1033
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> After migration to Hudson - the test takes far too long to run.
> It needs to be speeded up if it is to be any use.
> The clustering, bridge and thirdparty tests do not need to be run against all databases, only the invm and remote tests 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 lists.jboss.org  Thu Aug 23 14:32:18 2007
From: jira-events at lists.jboss.org (David Stroop (JIRA))
Date: Thu, 23 Aug 2007 14:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBADMCON-114)
 java.lang.ClassCastException: java.lang.OutOfMemoryError
Message-ID: <16912543.1187893938786.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBADMCON-114?page=comments#action_12373568 ] 
            
David Stroop commented on JBADMCON-114:
---------------------------------------

Also happens with 

Client:
IE6.0.2900.2180.xpsp_sp2_gdr.070227-2254

Java Plug-in 1.6.0_02
Using JRE version 1.6.0_02 Java HotSpot(TM) Client VM

http://64.109.44.20/web-console/Invoker
java.lang.ClassCastException: java.lang.OutOfMemoryError cannot be cast to java.lang.Exception
	at org.jboss.console.remote.Util.invoke(Util.java:80)
	at org.jboss.console.remote.AppletRemoteMBeanInvoker.invoke(AppletRemoteMBeanInvoker.java:50)
	at org.jboss.console.navtree.ConsoleTreeModel.loadTree(ConsoleTreeModel.java:104)
	at org.jboss.console.navtree.ConsoleTreeModel.<init>(ConsoleTreeModel.java:59)
	at org.jboss.console.navtree.AdminTreeBrowser.<init>(AdminTreeBrowser.java:63)
	at org.jboss.console.navtree.AppletBrowser.start(AppletBrowser.java:51)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Version: 4.0.3SP1(build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)
Version Name: Zion
Built on: October 23 2005 

Server:
OS: Linux 2.6.9-34.EL (i386)
JVM Version: 1.4.2_11-b06


Left panel is blank, right panel shows:
JBoss? Application Server
JBoss 
...
JVM - Hardware 
...


> java.lang.ClassCastException: java.lang.OutOfMemoryError
> --------------------------------------------------------
>
>                 Key: JBADMCON-114
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-114
>             Project: JBoss Admin Console
>          Issue Type: Bug
>          Components: General Console
>         Environment: Server: JBoss 4.0.1sp1 running on Win2003, JDK  1.5.0_02-b09 
> Client: XP, IE / Mozilla, JDK 1.5.0-b64 / 1.5.0_02-b09
>            Reporter: Paul Kuit
>
> Applet won?t show; stacktrace;
> running local on the server
> http://localhost/web-console/Invoker
> java.lang.ClassCastException: java.lang.OutOfMemoryError
> 	at org.jboss.console.remote.Util.invoke(Util.java:80)
> 	at org.jboss.console.remote.AppletRemoteMBeanInvoker.invoke(AppletRemoteMBeanInvoker.java:50)
> 	at org.jboss.console.navtree.ConsoleTreeModel.loadTree(ConsoleTreeModel.java:104)
> 	at org.jboss.console.navtree.ConsoleTreeModel.<init>(ConsoleTreeModel.java:59)
> 	at org.jboss.console.navtree.AdminTreeBrowser.<init>(AdminTreeBrowser.java:63)
> 	at org.jboss.console.navtree.AppletBrowser.start(AppletBrowser.java:51)
> 	at sun.applet.AppletPanel.run(Unknown Source)
> 	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 lists.jboss.org  Thu Aug 23 14:47:23 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1053) Write a test
 for JBMESSAGING-1031
Message-ID: <2848037.1187894843075.JavaMail.jira@cloud.prod.atl2.jboss.com>

Write a test for JBMESSAGING-1031
---------------------------------

                 Key: JBMESSAGING-1053
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1053
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.GA


I have fixed JBMESSAGING-1031 using a manual test.. we need to add a testcase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:47:23 2007
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Aug 2007 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1039) HTTP poller
	doesn't stop
In-Reply-To: <3265708.1186657442806.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30300908.1187894843267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1039?page=all ]

Tim Fox updated JBMESSAGING-1039:
---------------------------------

    Fix Version/s: 1.4.0.GA
                       (was: 1.4.0.CR2)

> HTTP poller doesn't stop
> ------------------------
>
>                 Key: JBMESSAGING-1039
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1039
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.GA
>
>
> I have temporarily commented out clusterviewupdatetst::testUpdateMixedConnectionFactory since, once started, the HTTP poller doesn't stop.
> Maybe this is a bug in remoting - need to investigate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:47:23 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1031) Potential bug
 in cancelling delivery
In-Reply-To: <7308115.1186597909336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3414986.1187894843416.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1031?page=all ]

Clebert Suconic closed JBMESSAGING-1031.
----------------------------------------

    Resolution: Done

> Potential bug in cancelling delivery
> ------------------------------------
>
>                 Key: JBMESSAGING-1031
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1031
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>         Attachments: test.patch
>
>
> Need to replicate and investigate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:49:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1054) Create a test
 where a client failing with a ClusteredCF
Message-ID: <13035907.1187894958217.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a test where a client failing with a ClusteredCF
-------------------------------------------------------

                 Key: JBMESSAGING-1054
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1054
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:51:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 14:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1027) Client
	updating fails
In-Reply-To: <21665903.1186597309399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4882515.1187895078334.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1027?page=all ]

Clebert Suconic closed JBMESSAGING-1027.
----------------------------------------

    Resolution: Done

> Client updating fails
> ---------------------
>
>                 Key: JBMESSAGING-1027
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1027
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Client side node list updating currently only occurs if there is an active connection on the connection factory.
> This means that if a connection factory is downloaded, then a node dies, or another joins, then a connectionm is created. The client side aspects will never know about the new topology.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:53:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Aug 2007 14:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-404) Create project site
 for jboss-deploy plugin.
In-Reply-To: <27716106.1187728638760.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5728710.1187895198282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-404?page=all ]

Paul Gier closed JBBUILD-404.
-----------------------------

    Resolution: Done

Plugin now has a site here http://labs.jboss.com/maven-jboss-deploy-plugin.

> Create project site for jboss-deploy plugin.
> --------------------------------------------
>
>                 Key: JBBUILD-404
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-404
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: maven-jboss-deploy-plugin
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: maven-jboss-deploy-plugin-1.4
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> There should be a project site that contains documentation for the plugin on jboss.org.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 14:55:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 14:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4623)
 org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer
 with incorrent domain name
In-Reply-To: <15836517.1187821338264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26152294.1187895318507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4623?page=all ]

William DeCoste updated JBAS-4623:
----------------------------------

    Priority: Minor  (was: Major)

> org.jboss.web.tomcat.service.session.JBossCacheCluster creates MBeanServer with incorrent domain name
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4623
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4623
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: William DeCoste
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> MBeanServerLocator.setJBoss(getMBeanServer()); can create an MBeanServer with domain "DefaultDomain" and register is with MBeanServerLocator as the "jboss" domain. This breaks MBeanServerLocator.locateJBoss().
> Let me know if you see what I mean - I can fix it. 
> I'm looking in Branch_4_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 lists.jboss.org  Thu Aug 23 14:59:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 23 Aug 2007 14:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1105) web.xml does not
 conform web-app_2_3.dtd
In-Reply-To: <3916092.1187585177133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1786072.1187895558428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1105?page=all ]

Fernando Meyer closed JBRULES-1105.
-----------------------------------

    Resolution: Done

element order does matter in web.xml 

> web.xml does not conform web-app_2_3.dtd
> ----------------------------------------
>
>                 Key: JBRULES-1105
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1105
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Glassfish
>            Reporter: Michael Max
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> web.xml does not comply with a http://java.sun.com/dtd/web-app_2_3.dtd specification. Because of that drools-jbrms.war cannot be deployed to the servers with a strict validation as Glassfish, just to JBoss AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 15:19:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 15:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4615) NamingContext caches
 stale Naming stub
In-Reply-To: <17323116.1187577725144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32886719.1187896758277.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4615?page=all ]

Brian Stansberry closed JBAS-4615.
----------------------------------

    Resolution: Done

> NamingContext caches stale Naming stub
> --------------------------------------
>
>                 Key: JBAS-4615
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4615
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> As an important performance optimization, org.jnp.interfaces.NamingContext statically caches a WeakReference to the "proxy" to the server-side Naming service.  In most cases this is either an RMI stub (non-HA naming service) or a proxy based on an HARMIClient (for HA-JNDI).  Either way, the cached object uses RMI to communicate with the server.
> This object becomes invalid if the server (non-HA case) or cluster (HA case) it was associated with is restarted.  The object in the restarted server-side RMI runtime will no longer match the client-side RMI stub, and an invocation over the stub will result in a java.rmi.NoSuchObjectException on the client.  NamingContext's caching of the RMI greatly increases the odds of this occuring.  If this occurs, the cache will be flushed and the next call will acquire a fresh stub from the server, but the client will get an exception on the first call.
> Proposed solution is discussed on forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 15:21:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 15:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4553) Organize cluster
 testsuite package
 to allow easy ant patternset control of what runs under what configs
In-Reply-To: <22873919.1184512683856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <350491.1187896878223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4553?page=all ]

Brian Stansberry closed JBAS-4553.
----------------------------------

    Resolution: Done

> Organize cluster testsuite package to allow easy ant patternset control of what runs under what configs
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4553
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4553
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 15:23:18 2007
From: jira-events at lists.jboss.org (sdf sdf (JIRA))
Date: Thu, 23 Aug 2007 15:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1047) Need APIs on
 BusinessCalendar for setting values that are currently supplied via
 jbpm.business.calendar.properties file.
Message-ID: <13562311.1187896998257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Need  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.
-------------------------------------------------------------------------------------------------------------------------

                 Key: JBPM-1047
                 URL: http://jira.jboss.com/jira/browse/JBPM-1047
             Project: JBoss jBPM
          Issue Type: Feature Request
            Reporter: sdf sdf
         Assigned To: Tom Baeyens


Holidays, business hours are currently supplied to JBPM via a properties file. It would be nice to have a programattic way to add, modify these without having to edit the properties 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 lists.jboss.org  Thu Aug 23 15:53:22 2007
From: jira-events at lists.jboss.org (Davy Toch (JIRA))
Date: Thu, 23 Aug 2007 15:53:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
Message-ID: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>

"ExpanderResolver was not set" when DSL and DRL in separate resource folders.
-----------------------------------------------------------------------------

                 Key: JBRULES-1119
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions: 3.0.5
         Environment: - Eclipse 3.2.1
- WinXP
            Reporter: Davy Toch
         Assigned To: Mark Proctor
            Priority: Minor
         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip


1. jbossrulesproject_one_resource_folder.zip

- DRL and DSL in one resource folder
- no problem

2. jbossrulesproject_two_resource_folders.zip

- DRL and DSL in separate resource folders
- causes error message : "ExpanderResolver was not set"

We actually prefer two separate resource folders, because the rules are generated during the ANT
build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
in 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 lists.jboss.org  Thu Aug 23 15:53:22 2007
From: jira-events at lists.jboss.org (Davy Toch (JIRA))
Date: Thu, 23 Aug 2007 15:53:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16475217.1187898802666.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1119?page=all ]

Davy Toch updated JBRULES-1119:
-------------------------------

    Attachment: jbossrulesproject_one_resource_folder.zip

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Mark Proctor
>            Priority: Minor
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Thu Aug 23 15:53:22 2007
From: jira-events at lists.jboss.org (Davy Toch (JIRA))
Date: Thu, 23 Aug 2007 15:53:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25459052.1187898802839.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1119?page=all ]

Davy Toch updated JBRULES-1119:
-------------------------------

    Attachment: jbossrulesproject_two_resource_folders.zip

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Mark Proctor
>            Priority: Minor
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Thu Aug 23 15:59:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Thu, 23 Aug 2007 15:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1063) Failing location
 determination tests
In-Reply-To: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19434154.1187899158395.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1063?page=all ]

Philippe Ombredanne reassigned JBRULES-1063:
--------------------------------------------

    Assignee: Kris Verlaenen  (was: Edson Tirelli)

Kris:
Could you review this?
I just would like you to review the two test quickly (the FAILING ones are the original ones) : http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14055#l212 

and here : 
http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14055#l1736

Th is about a change in whitespace handling that was introduced in eth paers.
I am not sure what are the implications for that.
I copied the 2 tests that failed, and made them pass (not whitespace at the end of the line) and kept the ones that failed prefixed with FAILING 

> Failing location determination tests
> ------------------------------------
>
>                 Key: JBRULES-1063
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Kris Verlaenen
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  
> Their name is prefixed with FAILING
> I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
> The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 16:01:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Aug 2007 16:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-407) Migrate
 microcontainer docbook gen to jdocbook plugin
Message-ID: <26415361.1187899278199.JavaMail.jira@cloud.prod.atl2.jboss.com>

Migrate microcontainer docbook gen to jdocbook plugin
-----------------------------------------------------

                 Key: JBBUILD-407
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-407
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Microcontainer should use the maven-jdocbook-plugin for it's doc generation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:08:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 23 Aug 2007 17:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4626) Javassist 3.6.0.CR1
Message-ID: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>

Javassist 3.6.0.CR1
-------------------

                 Key: JBAS-4626
                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:12:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 17:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1120) Implement Step
 Over for mvel debugger
Message-ID: <426588.1187903538246.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement Step Over for mvel debugger
-------------------------------------

                 Key: JBRULES-1120
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1120
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Ahti Kitsik
         Assigned To: Ahti Kitsik
             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 17:12:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 17:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-76) SecurityAssociation
 CallerPrincipal
Message-ID: <11020680.1187903538403.JavaMail.jira@cloud.prod.atl2.jboss.com>

SecurityAssociation CallerPrincipal
-----------------------------------

                 Key: SECURITY-76
                 URL: http://jira.jboss.com/jira/browse/SECURITY-76
             Project: JBoss Security and Identity Management
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0.1-BETA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0.1-GA


SecurityAssociation.getCallerPrincipal needs to return the principal from 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 lists.jboss.org  Thu Aug 23 17:14:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 17:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1120) Implement Step
 Over for mvel debugger
In-Reply-To: <426588.1187903538246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5219930.1187903658293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1120?page=all ]

Ahti Kitsik resolved JBRULES-1120.
----------------------------------

    Resolution: Done
      Assignee: Mark Proctor  (was: Ahti Kitsik)

done.

> Implement Step Over for mvel debugger
> -------------------------------------
>
>                 Key: JBRULES-1120
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1120
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Ahti Kitsik
>         Assigned To: Mark Proctor
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 17:19:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 17:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-76)
 SecurityAssociation and SecurityContext linkage
In-Reply-To: <11020680.1187903538403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27409513.1187903958223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-76?page=all ]

Anil Saldhana updated SECURITY-76:
----------------------------------

        Summary: SecurityAssociation and SecurityContext linkage  (was: SecurityAssociation CallerPrincipal)
    Description: 
SecurityAssociation.getCallerPrincipal needs to return the principal from the security context

Also setPrincipal and setCredential needs to be verified.

  was:SecurityAssociation.getCallerPrincipal needs to return the principal from the security context


> SecurityAssociation and SecurityContext linkage
> -----------------------------------------------
>
>                 Key: SECURITY-76
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-76
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.1-BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1-GA
>
>
> SecurityAssociation.getCallerPrincipal needs to return the principal from the security context
> Also setPrincipal and setCredential needs to be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:27:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Aug 2007 17:27:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-76) SecurityAssociation
 and SecurityContext linkage
In-Reply-To: <11020680.1187903538403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8240283.1187904438234.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-76?page=all ]

Anil Saldhana closed SECURITY-76.
---------------------------------

    Resolution: Done

Running org.jboss.test.securityassociation.LegacySecurityAssociationTestCase
Found log4j.xml: file:/C:/cygwin/home/asaldhana/security/security-jboss-sx/trunk/target/test-classes/log4j.xml
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec

> SecurityAssociation and SecurityContext linkage
> -----------------------------------------------
>
>                 Key: SECURITY-76
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-76
>             Project: JBoss Security and Identity Management
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0.1-BETA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0.1-GA
>
>
> SecurityAssociation.getCallerPrincipal needs to return the principal from the security context
> Also setPrincipal and setCredential needs to be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 17:29:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 17:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1038) Client side
 failover hopping does not work
In-Reply-To: <6280710.1186655329777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24346462.1187904558807.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1038?page=all ]

Clebert Suconic closed JBMESSAGING-1038.
----------------------------------------

    Resolution: Done

> Client side failover hopping does not work
> ------------------------------------------
>
>                 Key: JBMESSAGING-1038
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1038
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> If I create three servers, then lookup a connection factory, then kill one server, with no active connection, then the client will still think there are 3 servers.
> if I then attempt to failover onto a server that is dead, ClusteringAspect goes into a loop retrying ten times, but on the *same* server - i.e. it does not attempt to "hop".
> Instead it should iterate through the list of delegates trying each one in turn.
> Need to write a test for this 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 lists.jboss.org  Thu Aug 23 17:59:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 23 Aug 2007 17:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4626) Javassist 3.6.0.CR1
In-Reply-To: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5858748.1187906358244.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4626?page=all ]

Kabir Khan closed JBAS-4626.
----------------------------

    Resolution: Done

> Javassist 3.6.0.CR1
> -------------------
>
>                 Key: JBAS-4626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:20:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Aug 2007 18:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1091)
 NullPointerException when the
 'result' block of an 'accumulate' function returns null
In-Reply-To: <33247068.1187266457558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8785697.1187907618346.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1091?page=all ]

Edson Tirelli closed JBRULES-1091.
----------------------------------

    Resolution: Done

Ok, I added integration tests and null handling code in accumulate. Now if accumulate ever returns a null value, it will raise a RuntimeDroolsException with appropriate message.

Thanks for reporting.

> NullPointerException when the 'result' block of an 'accumulate' function returns null
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1091
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1091
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Alexandre Gattiker
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> java.lang.NullPointerException
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:73)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:34)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:57)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:48)
> 	at org.drools.reteoo.AccumulateNode.assertTuple(AccumulateNode.java:176)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:131)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:163)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1241)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:858)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at com.sample.DroolsTest.main(DroolsTest.java:28)
> Example rule:
> rule "Example"
> 	no-loop true
> 	when
> 		$d:		Double()
> 		from accumulate ( m : Message( $value: status ),
>                               init( double total = 0; ),
>                               action( System.out.println($value); ),
>                               result( null )
>                          )
> 	then
> 		System.out.println( "xx"); 
> 		
> 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 lists.jboss.org  Thu Aug 23 18:22:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 18:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1055) Previously
 downloaded ConnectionFactory can't be used after restart
Message-ID: <13862907.1187907738589.JavaMail.jira@cloud.prod.atl2.jboss.com>

Previously downloaded ConnectionFactory can't be used after restart
-------------------------------------------------------------------

                 Key: JBMESSAGING-1055
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1055
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR1
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1055) Previously
 downloaded ConnectionFactory can't be used after restart
In-Reply-To: <13862907.1187907738589.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12524778.1187907858405.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1055?page=all ]

Clebert Suconic closed JBMESSAGING-1055.
----------------------------------------

    Resolution: Done

> Previously downloaded ConnectionFactory can't be used after restart
> -------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1055
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1055
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:24:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4552) Move all cluster
 tests under the org.jboss.test.cluster package
In-Reply-To: <896060.1184512683733.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16278192.1187907858819.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4552?page=all ]

Brian Stansberry closed JBAS-4552.
----------------------------------

    Resolution: Done

> Move all cluster tests under the org.jboss.test.cluster package
> ---------------------------------------------------------------
>
>                 Key: JBAS-4552
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4552
>             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
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Get all the tests together for easier management.
> org.jboss.test.ha.farm
> org.jboss.test.ha.jmx
> org.jboss.test.testbeancluster
> org.jboss.test.cache

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:24:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 18:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4551) Rationalize
	clustering testsuite
In-Reply-To: <15876970.1184512455093.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32601968.1187907858951.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4551?page=all ]

Brian Stansberry closed JBAS-4551.
----------------------------------

    Resolution: Done

> Rationalize clustering testsuite
> --------------------------------
>
>                 Key: JBAS-4551
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4551
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Container task for reorganize discussed on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113548.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 18:32:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Aug 2007 18:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4401) Clustering unit
 test failures - UDP stack
In-Reply-To: <4622729.1178507222526.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13999345.1187908338286.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4401?page=all ]

Brian Stansberry resolved JBAS-4401.
------------------------------------

    Resolution: Incomplete Description

Resolving due to no response on what release or branch this issue is reported against.

> Clustering unit test failures - UDP stack
> -----------------------------------------
>
>                 Key: JBAS-4401
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4401
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: xiangyang wang
>         Assigned To: Brian Stansberry
>
> Resolve remaining clustering related unit test failures.  The testbeancluster.BeanClusterUnitTestCase.testStatefulPassiviationExpiration test needs to be made more robust.  On the http session cases, the teardown needs to allow enough time for session invalidation to propagate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 19:04:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1069) DSL sentence
 widget is too
 small and combobox with sentences should not be expanded
In-Reply-To: <21523644.1186685221254.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6933132.1187910258353.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1069?page=all ]

Ahti Kitsik closed JBRULES-1069.
--------------------------------

    Resolution: Done

> DSL sentence widget is too small and combobox with sentences should not be expanded
> -----------------------------------------------------------------------------------
>
>                 Key: JBRULES-1069
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1069
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Ahti Kitsik
>         Assigned To: Ahti Kitsik
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> Reported by Kris Verlaenen:
> There is still an issue with DSL in the guided editor:
> if you add a DSL sentence, fill in some values, and then try to add
> more sentences, the sentences shown in the drop-down box also contain
> the filled in values ?
> The size of the boxes in DSL sentences also seem to shrink to minimal
> when adding new sentences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 19:04:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1052) When Inserting a
 fact cannot set a String field
In-Reply-To: <1292464.1185911829398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4598699.1187910258806.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1052?page=all ]

Ahti Kitsik closed JBRULES-1052.
--------------------------------

    Resolution: Done

> When Inserting a fact cannot set a String field
> -----------------------------------------------
>
>                 Key: JBRULES-1052
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1052
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> A String field only let me put in numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 19:04:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 23 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1120) Implement Step
 Over for mvel debugger
In-Reply-To: <426588.1187903538246.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4917728.1187910258925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1120?page=all ]

Ahti Kitsik closed JBRULES-1120.
--------------------------------

    Assignee: Ahti Kitsik  (was: Mark Proctor)

> Implement Step Over for mvel debugger
> -------------------------------------
>
>                 Key: JBRULES-1120
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1120
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Ahti Kitsik
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.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 lists.jboss.org  Thu Aug 23 20:04:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 20:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1038) several classes
 check for RemoteBinding or RemoteBindings but not both
Message-ID: <17120176.1187913858226.JavaMail.jira@cloud.prod.atl2.jboss.com>

several classes check for RemoteBinding or RemoteBindings but not both
----------------------------------------------------------------------

                 Key: EJBTHREE-1038
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1038
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: AS 4.2.1.GA, AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1
            Reporter: William DeCoste
         Assigned To: William DeCoste
            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 lists.jboss.org  Thu Aug 23 21:05:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 23 Aug 2007 21:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1012)
 SeveralClientsStressTest leads to remoting dead lock
In-Reply-To: <18706398.1184093551579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10721464.1187917518500.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1012?page=all ]

Clebert Suconic closed JBMESSAGING-1012.
----------------------------------------

    Resolution: Done

I have executed the test several times, and didn't fail...

I have also executed the test for an hour (changing few parameters on the test), and the test supported the huge ammount of load.

> SeveralClientsStressTest leads to remoting dead lock
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1012
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1012
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.4.0.CR2
>
>
> SeveralClientsStressTest is not working...
> It looks like a racing between Timeouts and client.disconnect...
> Sometimes it fails, sometimes it locks 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 lists.jboss.org  Thu Aug 23 21:38:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 21:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26299815.1187919498444.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=all ]

William DeCoste reassigned EJBTHREE-1025:
-----------------------------------------

    Assignee: William DeCoste  (was: Carlo de Wolf)

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 22:26:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Thu, 23 Aug 2007 22:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8602225.1187922378546.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12373623 ] 
            
William DeCoste commented on EJBTHREE-1025:
-------------------------------------------

This is fixed in Branch_4_2. Do we want to port it to JBPAPP branches or just 5.0?

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:42:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25492749.1187926938459.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1116?page=comments#action_12373627 ] 
            
Mark Proctor commented on JBRULES-1116:
---------------------------------------

I'm pretty sure this is fixed. Stateless Session was not inserting the InitialFact. I'll add an integration for this, just in case.

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:44:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1104) Inserted
 Objects are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12731234.1187927058203.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1104?page=comments#action_12373628 ] 
            
Mark Proctor commented on JBRULES-1104:
---------------------------------------

This was slightly mistaken, internal Objects where lost, like InitialFactImpl

> Inserted Objects are lost if no matching ObjectTypeNodes
> --------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:46:25 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:46:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1104) Inserted internal
 Objects
 (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13727001.1187927185922.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1104?page=all ]

Mark Proctor updated JBRULES-1104:
----------------------------------

    Summary: Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes  (was: Inserted Objects are lost if no matching ObjectTypeNodes)

> Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:48:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1104) Inserted internal
 Objects (like
 InitialFactImpl)  are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7085099.1187927298197.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1104?page=all ]

Mark Proctor closed JBRULES-1104.
---------------------------------

    Resolution: Done

> Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 23 23:52:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 23 Aug 2007 23:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1104) Inserted
 internal Objects
 (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
In-Reply-To: <3898959.1187576281127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24332203.1187927538347.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1104?page=comments#action_12373629 ] 
            
Mark Proctor commented on JBRULES-1104:
---------------------------------------

The main things it does is create an ObjectTypeNode for an inserted object, if one does not exist for it. When a new ObjectTypenode is added the updateSink now just iterates the ObjectTypeConf (only exists for inserted conrete types) and pushes through the data from any matching ObjectTypeNodes - it also resets the cache on just those. So it no longer iterates the entire working memory and it selectively resets the cache.

> Inserted internal Objects (like InitialFactImpl)  are lost if no matching ObjectTypeNodes
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1104
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1104
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> We do not remember objects that have no matching ObjectTypeNodes. Instead we should keep a LinkedList of Ojects that do not have all their interfaces and superclasses matched by ObjectTypeNodes. This can be checked by the ObjectTypeConf which can cache the total number of interfaces and superclasses and compare the number against the ObjectTypeNode cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:01:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 00:01:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27879599.1187928079949.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1119?page=all ]

Mark Proctor updated JBRULES-1119:
----------------------------------

    Fix Version/s: 4.0.1
      Description: 
1. jbossrulesproject_one_resource_folder.zip

- DRL and DSL in one resource folder
- no problem

2. jbossrulesproject_two_resource_folders.zip

- DRL and DSL in separate resource folders
- causes error message : "ExpanderResolver was not set"

We actually prefer two separate resource folders, because the rules are generated during the ANT
build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
in src/...).

  was:

1. jbossrulesproject_one_resource_folder.zip

- DRL and DSL in one resource folder
- no problem

2. jbossrulesproject_two_resource_folders.zip

- DRL and DSL in separate resource folders
- causes error message : "ExpanderResolver was not set"

We actually prefer two separate resource folders, because the rules are generated during the ANT
build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
in src/...).

         Assignee: Michael Neale  (was: Mark Proctor)

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: 4.0.1
>
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Fri Aug 24 00:03:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 00:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20026611.1187928198354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1109?page=all ]

Mark Proctor updated JBRULES-1109:
----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Michael Neale  (was: Fernando Meyer)

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:05:53 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 00:05:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17260217.1187928353935.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1106?page=all ]

Mark Proctor updated JBRULES-1106:
----------------------------------

    Fix Version/s: 4.0.1
         Assignee: Michael Neale  (was: Mark Proctor)

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:05:54 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Fri, 24 Aug 2007 00:05:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <500544.1187928354086.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1109?page=comments#action_12373631 ] 
            
Michael Neale commented on JBRULES-1109:
----------------------------------------

This is according to the JCR spec (I think) - it is stated also in the manual that the version history is not supported (the GUI said backup/restore - which is not technically correct).

Will look into ways to achieve this, but I am not sure if there is an easy way at hand. 

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 00:16:35 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Fri, 24 Aug 2007 00:16:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10048802.1187928995468.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1106?page=comments#action_12373632 ] 
            
Michael Neale commented on JBRULES-1106:
----------------------------------------

Hmmm yes - I think the name of the rule in the drl shoudl be the name of the asset - not whatever it things it was from the old rule (ie it is copying the name across to the new name - not really that helpful !). well spotted !

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 02:39:29 2007
From: jira-events at lists.jboss.org (sreeni sabapathy (JIRA))
Date: Fri, 24 Aug 2007 02:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1121) Operator field
 and the fact's
 variable field required in the "then" part of the rule
Message-ID: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>

Operator field and the fact's variable field required in the "then" part of the rule
------------------------------------------------------------------------------------

                 Key: JBRULES-1121
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-brms, Eclipse IDE
    Affects Versions:  4.0.0.GA
         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
            Reporter: sreeni sabapathy
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
But in many condition the the value of the variable depends upon the value of another variable.

I have taken  a simple example for explanation.

For calcluating simple interest

SI = P*T*R/100

Now in the rule file if the 

"when" condition as the check of " Calcluation type (simple ineterst or compound interest)"

"then" part having SI, 

At the present drool-jbrms definition the 

"then" part has SI = text field.

But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
assign some fixed values.

In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 03:07:18 2007
From: jira-events at lists.jboss.org (Gabriele Garuglieri (JIRA))
Date: Fri, 24 Aug 2007 03:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1037)
 JDBCPersistenceManager.java - reference should be inserted after message
 (ORA-02291: integrity constraint)
In-Reply-To: <21939514.1186653049587.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31914048.1187939238941.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1037?page=comments#action_12373635 ] 
            
Gabriele Garuglieri commented on JBMESSAGING-1037:
--------------------------------------------------

Being bitten by the same problem with Postgres.
1.4.0.CR1 looks to be completely unusable because it fails with constraint violation as soon as i try to send a message.

> JDBCPersistenceManager.java - reference should be inserted after message (ORA-02291: integrity constraint)
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1037
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1037
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>         Environment: Windows XP / Oracle 10g
>            Reporter: Mariusz Olejnik
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.4.0.CR1
>
>         Attachments: jboss-messaging-trunk-rev2988.patch
>
>
> Reference should be inserted after message because:
> oracle-persistence-service.xml 
> CREATE TABLE JBM_MSG_REF (
>   CHANNEL_ID INTEGER, 
>   MESSAGE_ID INTEGER REFERENCES JBM_MSG(MESSAGE_ID) 
> [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 03:25:20 2007
From: jira-events at lists.jboss.org (Gabriele Garuglieri (JIRA))
Date: Fri, 24 Aug 2007 03:25:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1056) JBM_MSG_REF
 table must be created after JBM_MSG
Message-ID: <13693640.1187940320838.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBM_MSG_REF table must be created after JBM_MSG
-----------------------------------------------

                 Key: JBMESSAGING-1056
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1056
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
         Environment: Java 1.6.0_02-b06
JBoss 4.2.1.GA
Jbmessaging 1.4.0.CR1
PostgreSQL 8.2.4
            Reporter: Gabriele Garuglieri
         Assigned To: Tim Fox


At the first startup on a clean db the creation of JBM_MSG_REF table fails with error:
org.postgresql.util.PSQLException: ERROR: relation "jbm_msg" does not exist
because it now has a relation with JBM_MSG table that is not yet created.
The situation gets cleaned up after a restart because on the second run it finds JBM_MSG table and is able to proceed with JBM_MSG_REF table creation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 04:08:18 2007
From: jira-events at lists.jboss.org (gerald zhou (JIRA))
Date: Fri, 24 Aug 2007 04:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1057)
 java.io.IOException:
 EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment
Message-ID: <17912445.1187942898273.JavaMail.jira@cloud.prod.atl2.jboss.com>

java.io.IOException: EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment
-------------------------------------------------------------------------------

                 Key: JBMESSAGING-1057
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1057
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Remoting
    Affects Versions: 1.2.0.SP1
         Environment: boss-4.0.5.GA, java 1.4.2_07 , jboss messaging 1.2.0.SP1
            Reporter: gerald zhou
         Assigned To: Tim Fox


java.io.IOException: EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
        at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
        at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:367)
        at EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap.writeObject(Unknown Source)
        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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
        at org.jboss.jms.wireformat.SerializedPacket.write(SerializedPacket.java:80)
        at org.jboss.jms.server.remoting.JMSWireFormat.write(JMSWireFormat.java:245)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:958)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:552)
        at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:339)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
        at org.jboss.remoting.LeasePinger.sendClientPing(LeasePinger.java:283)
        at org.jboss.remoting.LeasePinger.access$000(LeasePinger.java:20)
        at org.jboss.remoting.LeasePinger$LeaseTimerTask.run(LeasePinger.java:315)
        at java.util.TimerThread.mainLoop(Timer.java:432)
        at java.util.TimerThread.run(Timer.java:382)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 04:22:18 2007
From: jira-events at lists.jboss.org (dana enescu (JIRA))
Date: Fri, 24 Aug 2007 04:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1169) some methods in
 eviction queue
 classes have package-only visibility - can it be changed?
Message-ID: <31734798.1187943738292.JavaMail.jira@cloud.prod.atl2.jboss.com>

some methods in eviction queue classes have package-only visibility - can it be changed?
----------------------------------------------------------------------------------------

                 Key: JBCACHE-1169
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1169
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eviction
    Affects Versions: 2.0.0.GA
            Reporter: dana enescu
         Assigned To: Manik Surtani
            Priority: Minor


I have been trying to implement my own cache eviction policy. The most convenient way for me was to extend LFU, instead of implementing the interfaces from scratch.
However, the ctor and the prune() method in LFUQueue have package-only visibility, so I had to do a nasty workaround. There may be similar issues in other classes of the eviction package. 

IMO it would be better that these methods are made either public or protected, depending on what you want to expose to the users. I did not report it as a bug but rather as a feature request, since I do not know the developer's intent.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 05:47:02 2007
From: jira-events at lists.jboss.org (Suman Ghosh (JIRA))
Date: Fri, 24 Aug 2007 05:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1122) Eclipse-JDT
 compiler jar
 (core-3.2.0.666.jar) for drools creates problems/conflicts with the
 existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
Message-ID: <527189.1187948822233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eclipse-JDT compiler jar (core-3.2.0.666.jar) for drools creates problems/conflicts with the existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-1122
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1122
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA, 3.0.6
         Environment: Windows XP / JDK 1.5.0_06-b05
            Reporter: Suman Ghosh
         Assigned To: Mark Proctor


I'm running a service using JBoss, which uses Drools for its various rule-based components. The propblem arises like this -  when I use the JDTcompiler in Drools, tomcat crashes with the following stacktrace (when used to access JSPs - such as the JBoss JMX console)....

----------------------------------------------------START-------------------------------------------------------------------
type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:272)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

root cause

java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
	org.apache.jasper.compiler.JDTCompiler$2.acceptResult(JDTCompiler.java:345)
	org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417)
	org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:404)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:297)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
---------------------------------------------------END--------------------------------------------------------------------

Seems that the class CompilationResult from the new JDT distribution has a different signature for the getProblems() method - but tomcat expects the earlier one only.

For my application, I *have* to use the JDT compiler for my rule base, and on the other hand, I require the jboss jmx-console, for service monitoring and method invokations :(

Please suggest a solution!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 05:53:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 24 Aug 2007 05:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1063) Failing location
 determination tests
In-Reply-To: <17141715.1186446169456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9025771.1187949198716.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1063?page=all ]

Kris Verlaenen resolved JBRULES-1063.
-------------------------------------

    Resolution: Done

Updated location determination to fix tests

> Failing location determination tests
> ------------------------------------
>
>                 Key: JBRULES-1063
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1063
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>    Affects Versions: 4.0.1
>            Reporter: Philippe Ombredanne
>         Assigned To: Kris Verlaenen
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> We have four failing tests in that code : org.drools.eclipse.editors.completion.CompletionContextTest ( http://fisheye.jboss.com/browse/JBossRules/trunk/drools-eclipse/drools-eclipse-test/src/test/java/org/drools/eclipse/editors/completion/CompletionContextTest.java?r=14038 ) that I isolated in separate test methods, and prefixed so they would not make the build fail.  
> Their name is prefixed with FAILING
> I am not sure why they started to fail (I know why, but I do not understand exactly the rationale for the tests being made) , but  possibly some changes in the DrlParser handling of trailing white spaces could have triggered that. 
> The white space issue could be coming from that rev : http://fisheye.jboss.com/changelog/JBossRules/trunk/drools-compiler/src/main/resources/org/drools?cs=13943

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 05:57:39 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Fri, 24 Aug 2007 05:57:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1048) Context assist
 is not working for DSLs in Eclipse
In-Reply-To: <29452179.1185834177693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17480318.1187949459928.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1048?page=all ]

Kris Verlaenen resolved JBRULES-1048.
-------------------------------------

    Resolution: Done

Renamed *.drl using dsl to *.dslr

> Context assist is not working for DSLs in Eclipse
> -------------------------------------------------
>
>                 Key: JBRULES-1048
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1048
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> the expander is set, but context assist is not working. See the TroubleTicketWithDSL 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 lists.jboss.org  Fri Aug 24 06:17:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 24 Aug 2007 06:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-1047) Provice APIs on
 BusinessCalendar for setting values that are currently supplied via
 jbpm.business.calendar.properties file.
In-Reply-To: <13562311.1187896998257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12936147.1187950638351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-1047?page=all ]

Ronald van Kuijk updated JBPM-1047:
-----------------------------------

              Summary: Provice  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.  (was: Need  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.)
          Component/s: Core Engine
        Fix Version/s: jBPM 4.0
    Affects Version/s:  jBPM jPDL 3.2.1
             Priority: Optional  (was: Major)

Please be a little more specific.... 

> Provice  APIs on BusinessCalendar for setting values that are currently supplied via jbpm.business.calendar.properties file.
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPM-1047
>                 URL: http://jira.jboss.com/jira/browse/JBPM-1047
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions:  jBPM jPDL 3.2.1
>            Reporter: sdf sdf
>         Assigned To: Tom Baeyens
>            Priority: Optional
>             Fix For: jBPM 4.0
>
>
> Holidays, business hours are currently supplied to JBPM via a properties file. It would be nice to have a programattic way to add, modify these without having to edit the properties 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 lists.jboss.org  Fri Aug 24 07:41:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 07:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-455) Upgrade javassist to
	3.6.0.CR2
Message-ID: <22621436.1187955678243.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade javassist to 3.6.0.CR2
------------------------------

                 Key: JBAOP-455
                 URL: http://jira.jboss.com/jira/browse/JBAOP-455
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.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 lists.jboss.org  Fri Aug 24 07:43:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 07:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-454) Upgrade jboss retro
	to 1.1.2
In-Reply-To: <31251926.1187351581112.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29970387.1187955798288.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-454?page=all ]

Kabir Khan closed JBAOP-454.
----------------------------

    Resolution: Done
      Assignee: Kabir Khan  (was: Flavia Rainone)

Build and install scripts have been modified to use the right names (this version of retro uses different names for the jars than previously)

> Upgrade jboss retro to 1.1.2
> ----------------------------
>
>                 Key: JBAOP-454
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-454
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.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 lists.jboss.org  Fri Aug 24 07:49:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 07:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1116) "not" doesn't
 work for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26063458.1187956158394.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1116?page=comments#action_12373667 ] 
            
Mark Proctor commented on JBRULES-1116:
---------------------------------------

This was fixed as part of  JBRULES-1104, I've added the unit test anyway to catch future regressions.

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 07:49:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 07:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1116) "not" doesn't work
 for StatelessSessions
In-Reply-To: <24789195.1187877258308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31735536.1187956158588.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1116?page=all ]

Mark Proctor closed JBRULES-1116.
---------------------------------

    Resolution: Done

> "not" doesn't work for StatelessSessions
> ----------------------------------------
>
>                 Key: JBRULES-1116
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1116
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> When using a StatelessSession, the "not" quantifier doesn't work. Test case below.
> package org.drools.examples
> rule "Hello World"
>        when
>            Integer()
>        then
>            System.out.println("Hello world");
> end
> rule "Goodbye World"
>        when
>            not Integer()
>        then
>            System.out.println("Goodbye cruel world");
> end
> public class TestReadRuleFile {
>  public static void main(String[] args) throws Exception {
>   PackageBuilder builder = new PackageBuilder();
>   InputStreamReader is = new InputStreamReader(
>    TestReadRuleFile.class.getResourceAsStream("test.drl"));
>   builder.addPackageFromDrl(is);
>   Package pkg = builder.getPackage();
>   RuleBase jbossRulebase = RuleBaseFactory.newRuleBase();
>   jbossRulebase.addPackage(pkg);
>   StatelessSession session = jbossRulebase.newStatelessSession();
>   session.execute(new Float(1));
>  }
> }
> The "Goodbye world" rule should fire (there are no Integers in the working memory) but doesn't. If you switch to a StatefulSession, the "Goodbye world" rule does fire.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 07:58:29 2007
From: jira-events at lists.jboss.org (Gokhan Demir (JIRA))
Date: Fri, 24 Aug 2007 07:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4609) Original
 SevletResponse or
 wrapped original ServletResponse not passed to RequestDispatcher in
 violation of SRV.8.2 and SRV.14.2.5.1
In-Reply-To: <14152110.1187166841533.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29643548.1187956709912.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4609?page=comments#action_12373670 ] 
            
Gokhan Demir commented on JBAS-4609:
------------------------------------

The same error happening in my production web application, for version 4.2.1.GA. It is not reproducable, just randomly happening.

> Original SevletResponse or wrapped original ServletResponse not passed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4609
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4609
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.2.0.GA
>         Environment: RHeL
>            Reporter: stefan lotties
>
> Sometimes in the log the following stacktrace appears while someone is surfing in an application:
> 2007-08-09 12:10:01,834 [http-0.0.0.0-8080-1] ERROR org.apache.catalina.core.ContainerBase.[jboss.we
> b].[localhost].[/webadmin].[action] - Servlet.service() for servlet action threw exception
> javax.servlet.ServletException: Original SevletResponse or wrapped original ServletResponse not pass
> ed to RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
>         at org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.jav
> a:1018)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:329)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056)
>         at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261)
>         at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcesso
> r.java:237)
>         at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.
> java:300)
>         at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231)
>         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
>         at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
>         at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:271)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
> ava:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
>         at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:
> 469)
>         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
>         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>         at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.
> java:316)
>         at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:2
> 44)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:
> 156)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
> va:580)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595) 
> I debugged as far as I could and noticed that the http-request returns the host the jboss runs on when calling HttpServletRequest.getRemoteHost() and has "HEAD" as method. It can't be reproduced since it seems to be kinda random (doing the same action twice or more often does not end in this exception). Also the requested-URIs are different. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 09:04:35 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:04:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
Message-ID: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>

Timer task throws exception on task submission if task has already been cancelled
---------------------------------------------------------------------------------

                 Key: JGRP-582
                 URL: http://jira.jboss.com/jira/browse/JGRP-582
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5.1, 2.6


When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
SOLUTION: simply catch and eat the exception

@FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
java.lang.IllegalStateException: Timer already cancelled.
        at java.util.Timer.sched(Timer.java:354)
        at java.util.Timer.schedule(Timer.java:170)
        at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
        at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
        at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
        at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
        at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
        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 lists.jboss.org  Fri Aug 24 09:11:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26093651.1187961078448.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-582?page=comments#action_12373686 ] 
            
Bela Ban commented on JGRP-582:
-------------------------------

Note that this can also happen if we submit a task to a timer that has already been cancelled

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:13:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9324642.1187961198294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-582?page=all ]

Bela Ban updated JGRP-582:
--------------------------

    Fix Version/s: 2.4.1 SP5

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1, 2.4.1 SP5
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:16:11 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19921189.1187961371958.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-582?page=comments#action_12373688 ] 
            
Bela Ban commented on JGRP-582:
-------------------------------

We don't need to fix this in 2.5 and 2.6

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1, 2.4.1 SP5
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:16:12 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Aug 2007 09:16:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-582) Timer task throws
 exception on task submission if task has already been cancelled
In-Reply-To: <5466597.1187960675771.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10652112.1187961372074.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-582?page=all ]

Bela Ban resolved JGRP-582.
---------------------------

    Resolution: Done

> Timer task throws exception on task submission if task has already been cancelled
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-582
>                 URL: http://jira.jboss.com/jira/browse/JGRP-582
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4.1 SP5, 2.5.1, 2.6
>
>
> When we submit a timer task to a timer, but - before the timer is scheduled - it is cancelled, then we get the exception below.
> SOLUTION: simply catch and eat the exception
> @FD_SOCK Ping thread 09:43:17,125 ERROR [jgroups] uncaught exception in Thread[FD_SOCK Ping thread,5,JGroups threads] (thread group=org.jgroups.util.Util$1[name=JGroups threads,maxpri=10] )
> java.lang.IllegalStateException: Timer already cancelled.
>         at java.util.Timer.sched(Timer.java:354)
>         at java.util.Timer.schedule(Timer.java:170)
>         at org.jgroups.util.TimeScheduler.schedule(TimeScheduler.java:125)
>         at org.jgroups.util.TimeScheduler.add(TimeScheduler.java:112)
>         at org.jgroups.protocols.FD_SOCK$BroadcastTask.addSuspectedMember(FD_SOCK.java:1186)
>         at org.jgroups.protocols.FD_SOCK.broadcastSuspectMessage(FD_SOCK.java:721)
>         at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:453)
>         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 lists.jboss.org  Fri Aug 24 09:56:18 2007
From: jira-events at lists.jboss.org (Manik Surtani (JIRA))
Date: Fri, 24 Aug 2007 09:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1167) Heuristic outcome
 (STATUS_UNKNOWN) of transaction not handled properly
In-Reply-To: <9760798.1187716218788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24294005.1187963778285.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1167?page=all ]

Manik Surtani closed JBCACHE-1167.
----------------------------------

    Fix Version/s: 2.1.0.GA
       Resolution: Done

> Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
> ----------------------------------------------------------------------
>
>                 Key: JBCACHE-1167
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1167
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.SP4, 2.0.0.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Manik Surtani
>             Fix For: 1.4.1.SP5, 2.1.0.GA
>
>
> Where an XA transaction has a heuristic outcome, the status reported to 
> the afterCompletion synchronization is STATUS_UNKNOWN (5), since 
> JTA does not handle heuristics. In this case, the cache Synchronization 
> fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked) 
> state even though the XA transaction has been resolved. 
> At first glance it looks like the afterCompletion synchronization should treat a 
> STATUS_UNKNOWN as a cause for rollback as well as logging the error as 
> they currently do. Unfortunately the fix may be more complex than that, since 
> the db may have committed rather than rolled back, meaning the cache would 
> be out of sync with the db if you rolled it 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 lists.jboss.org  Fri Aug 24 10:06:18 2007
From: jira-events at lists.jboss.org (Jiri Pechanec (JIRA))
Date: Fri, 24 Aug 2007 10:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1058) Table
 jbm_msg_ref constraint violation
Message-ID: <31519789.1187964378345.JavaMail.jira@cloud.prod.atl2.jboss.com>

Table jbm_msg_ref constraint violation
--------------------------------------

                 Key: JBMESSAGING-1058
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1058
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
         Environment: RHEL 5, PostgreSQL 8.2, JBoss ESB
            Reporter: Jiri Pechanec
         Assigned To: Tim Fox
            Priority: Critical


When trying to send a message I am getting exception
17:04:35,127 WARN  [JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
org.postgresql.util.PSQLException: ERROR: insert or update on table "jbm_msg_ref" violates foreign key constraint "jbm_msg_ref_message_id_fkey"
  Detail: Key (message_id)=(8192) is not present in table "jbm_msg".
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1525)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1309)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:308)
        at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2915)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2786)
        at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1284)
        at org.jboss.messaging.core.impl.ChannelSupport.handleInternal(ChannelSupport.java:613)
        at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:148)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2101)
        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:505)
        at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:707)
        at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:343)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:80)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
        at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:152)
        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.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
        at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
        at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
        at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:85)
        at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 10:26:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 10:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1119) "ExpanderResolver
 was not set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15518639.1187965578283.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1119?page=all ]

Fernando Meyer updated JBRULES-1119:
------------------------------------

       Issue Type: Feature Request  (was: Bug)
    Fix Version/s: FUTURE
                       (was: 4.0.1)

It's not a bug, It's more an enhancement request. I will left it opened for future versions

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Fri Aug 24 10:35:33 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 10:35:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <15722408.1187966133086.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=all ]

Fernando Meyer updated JBRULES-1112:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 10:35:33 2007
From: jira-events at lists.jboss.org (Huishan Zhou (JIRA))
Date: Fri, 24 Aug 2007 10:35:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <8810911.1187966133314.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=all ]

Huishan Zhou updated JBRULES-1112:
----------------------------------

    Fix Version/s: 4.0.1
                       (was: FUTURE)

I didn't find jboss-faces.jar inside JBoss4.0.5.  I searched the internet, and find it from
http://www.icefaces.org/JForum/posts/downloadAttach/1321.page together with the other
two files jsf-impl.jar and jsf-api.jar.

I add these three jars to WEB-INF/lib to test drools-jbrms.war in both  "single Jetty-6.1.1", and "JBoss-4.0.5GA bundled with Jetty-6.1.1".

They still have the problem (error message can be provided on request).  Please send me your three jar files, so that I can test your three jars with drools-jbrms.war.

We can only find lower version of JBoss bundled with Jetty in your website.  We create JBoss-4.0.5-GA bundled with Jetty-6.1.1 ourselves because we need some special features of Jetty6.1.1.
But we create this bundle based on the instruction provided by your website and Jetty.

We can contribute this bundle to you if you need.  This bundle works fine with many other examples, and has special features of working with continuation and cometd.  But this bundle also has some problems in a few other examples such as drools-jbrms.war.

Please beaware that in the selection on affected version of this page, the highest version is 4.0.1. there is no place for version 4.0.5 which is also not the future version since this version already existed on your site.



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 10:56:18 2007
From: jira-events at lists.jboss.org (Ross McDonald (JIRA))
Date: Fri, 24 Aug 2007 10:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-151) entries in mail node
 subject and
 body elements disappear depending on click order before save
Message-ID: <17748603.1187967378477.JavaMail.jira@cloud.prod.atl2.jboss.com>

entries in mail node subject and body elements disappear depending on click order before save
---------------------------------------------------------------------------------------------

                 Key: GPD-151
                 URL: http://jira.jboss.com/jira/browse/GPD-151
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM JPDL Designer 3.1.0.CR
         Environment: os x, eclipse 3.3.0, 
            Reporter: Ross McDonald
         Assigned To: Koen Aers
            Priority: Critical


when I enter text in a mail node 'subject' input box, if I just click straight on the save button in eclipse, I lose the text entered...
the same is true of the 'body' input box on the mail node

to get this process to work I need to enter my text in the 'subject' input box, then click on the body input box, then click on the save button on the toolbar, this ensures my entry is in fact saved



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 11:27:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 11:27:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28876930.1187969238722.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1109?page=comments#action_12373711 ] 
            
Fernando Meyer commented on JBRULES-1109:
-----------------------------------------

Michale is right the JCR doesn't keep node version history, I will leave it for future version 

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: 4.0.1
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 11:29:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 11:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1109) Exported BRMS
 repositories lose version history
In-Reply-To: <19027500.1187780418378.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16595011.1187969358471.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1109?page=all ]

Fernando Meyer updated JBRULES-1109:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Exported BRMS repositories lose version history
> -----------------------------------------------
>
>                 Key: JBRULES-1109
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1109
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, SUN JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Michael Neale
>             Fix For: FUTURE
>
>
> I've come across an issue with exporting and importing a BRMS repository backup, which I'm not sure is a feature or a bug. I have a package that contains a bunch of rules I've developed. I've modified and saved rules, so that most of the rules have a fairly long history when you select the Version History in the rule view. If I export the repository in the Admin/Manage Backups section and then import the repository into a clean BRMS installation, all the version history of the rules seems to be lost. The rules still have the correct version attribute (e.g. version: 8 etc), but when you click on the View History link it just says No History.
> If you actually export and then re-import the rules into the same BRMS installation, then the History is maintained - however, I suspect that is purely by chance as the underlying repository is not being cleaned up by the import option?
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new technical rule called test as shown below:
> when
>     eval(true)
> then
>     System.out.println("Hello");
> 3. Save the test rule
> 4. Modify test rule e.g. by changing "Hello" to "Hello World" and Save the rule agin to get a version 2 of the rule.
> 5. Click on the View History option to verify that the rule has a single historical version 1 in the repository.
> 6. From Admin/Manage Backups save the repository.
> 7. In a new clean BRMS install import the previously exported repository (I guess if you do not want to reinstall the BRMS you can shutdown the original and remove the repository directory, the repository.xml and derby.log files, and then restart to get an empty repository).
> 8. Open the test rule created previously. It should show up with version 2. Click on the View History option and it says No History. The conclusion is that the back feaure does not back up the full repository i.e. history is lost.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 11:43:18 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 24 Aug 2007 11:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMICROCONT-181) ManagedObject
	support
In-Reply-To: <29484599.1183399437650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30810657.1187970198505.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-181?page=all ]

Scott M Stark reassigned JBMICROCONT-181:
-----------------------------------------

    Assignee: Scott M Stark  (was: Adrian Brock)

> ManagedObject support
> ---------------------
>
>                 Key: JBMICROCONT-181
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-181
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Scott M Stark
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Add support for creating ManagedObjects 
> 1) From annotations on classes
> 2) By overrides from xml/other mechanisms
> Support different ManagedObject use cases, e.g. 
> * flat model - simple 
> * flattening model - multiple classes in (multiple) trees of object appear as one flat model
> * sets/maps/collections etc.
> * annotations
> * 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 lists.jboss.org  Fri Aug 24 11:45:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1170) Partial state
 transfer fails when multiple regions present
Message-ID: <5358429.1187970318264.JavaMail.jira@cloud.prod.atl2.jboss.com>

Partial state transfer fails when multiple regions present
----------------------------------------------------------

                 Key: JBCACHE-1170
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1170
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani


The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  

Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:

2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state

The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped".

Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:

1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.

2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should 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 lists.jboss.org  Fri Aug 24 12:02:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 12:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1112)
 drools-jbrms.war does not
 work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <17669341.1187971338528.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=comments#action_12373721 ] 
            
Fernando Meyer commented on JBRULES-1112:
-----------------------------------------

The main difference I can see is that you putting jars into WEB-INF/lib and Im putting jar into the app server lib directory 
also did you get a fresh brms war from downloadspage ? with no changed files? 

Use the latest BRMS version from here. 
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules/drools-4.0.1.SNAPSHOT-brms.zip



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: 4.0.1
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 12:04:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 12:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1170) Partial state
 transfer fails when multiple regions present
In-Reply-To: <5358429.1187970318264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31124790.1187971458782.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1170?page=all ]

Brian Stansberry updated JBCACHE-1170:
--------------------------------------

    Description: 
The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  

Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:

2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state

The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all.

Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:

1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.

2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should work.

  was:
The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  

Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:

2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state

The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped".

Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:

1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.

2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should work.


> Partial state transfer fails when multiple regions present
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1170
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1170
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>
> The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  
> Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state
> The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all.
> Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:
> 1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.
> 2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should 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 lists.jboss.org  Fri Aug 24 12:08:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 12:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <16177178.1187971698373.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=all ]

Fernando Meyer updated JBRULES-1112:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

Its not a bug, I some configuration issue.  4.0.1 is outing today so I will leave open for FUTURE assignment  I sill need two things, a bundle to integrate with jboss for test, the jetty website is down today (sic), when its online theres no valid  bundle for jboss. The other one, please test with a fresh jetty server running standalone. 

Fernando



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: FUTURE
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Fri Aug 24 12:20:20 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 12:20:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4546) Fix
	RunAsSecurityInterceptor
In-Reply-To: <519744.1184331123674.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26315819.1187972420504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4546?page=all ]

Kabir Khan closed JBAS-4546.
----------------------------

    Resolution: Done

> Fix RunAsSecurityInterceptor
> ----------------------------
>
>                 Key: JBAS-4546
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4546
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: AOP
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: JBossAS-4.2.2.GA
>
>
> Add this fix once branch is no longer frozen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 12:45:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 12:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-450) AOP/MC Proxies do not
 include original Annotation and Signature attributes
In-Reply-To: <3616832.1185675287117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18984491.1187973918236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-450?page=all ]

Kabir Khan closed JBAOP-450.
----------------------------

    Resolution: Done

Latest javassist snapshot should fix this issue. Contains fix which will be in 3.6.0.CR2

> AOP/MC Proxies do not include original Annotation and Signature attributes
> --------------------------------------------------------------------------
>
>                 Key: JBAOP-450
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-450
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.beta
>
>         Attachments: test.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 lists.jboss.org  Fri Aug 24 13:28:19 2007
From: jira-events at lists.jboss.org (Arch (JIRA))
Date: Fri, 24 Aug 2007 13:28:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-691) Decision class does
 not allow setting of Decision Delegation
In-Reply-To: <31453146.1152625331489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10969158.1187976499303.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-691?page=comments#action_12373733 ] 
            
Arch commented on JBPM-691:
---------------------------

The org.jbpm.graph.def.Action class already has a method setActionDelegation() to permit the ActionHandler to be set programatically, so it seems reasonable to add a similar method to the Decision class as well.  Instead of hardcoding class names in the XML, I create an XML template of the workflow and programatically inject the ActionHandlers, DecisionHandlers, etc. prior to deployment.

> Decision class does not allow setting of Decision Delegation
> ------------------------------------------------------------
>
>                 Key: JBPM-691
>                 URL: http://jira.jboss.com/jira/browse/JBPM-691
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Windows XP
> MySQL
> WSAD 5.1.2
>            Reporter: Chris OBrien
>         Assigned To: Tom Baeyens
>
> In programmatically creating/manipulating a process definition, one cannot specify a Decision Delegation on a Decision node.
> The Decision class just needs a method like:
>   public void setDecisionDelegation( Delegation del ) {
> 	  this.decisionDelegation = del;
>   }
> I have added this to my install, and it allows me to programmatically change the process definition to define the handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 13:38:19 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 13:38:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-4626) Javassist 3.6.0.CR1
In-Reply-To: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14161400.1187977099780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4626?page=all ]

Kabir Khan reopened JBAS-4626:
------------------------------

             

> Javassist 3.6.0.CR1
> -------------------
>
>                 Key: JBAS-4626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 13:38:20 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Aug 2007 13:38:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4626) Javassist 3.6.0.CR2
In-Reply-To: <22609030.1187903298222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20890057.1187977100693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4626?page=all ]

Kabir Khan updated JBAS-4626:
-----------------------------

    Summary: Javassist 3.6.0.CR2  (was: Javassist 3.6.0.CR1)

> Javassist 3.6.0.CR2
> -------------------
>
>                 Key: JBAS-4626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4626
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 14:25:28 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 14:25:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1171) Make constructor
 Fqn(List<E> names, boolean safe) public
Message-ID: <4725833.1187979928897.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make constructor Fqn(List<E> names, boolean safe) public
--------------------------------------------------------

                 Key: JBCACHE-1171
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1171
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.0.0.GA
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
            Priority: Minor


This constructor saves the cost of making a defensive copy of the passed in List.  I've got some code that necessarily creates an ArrayList to pass to the Fqn c'tor, but there's no need to copy it; I hold no ref to the List.  Being able to use this c'tor would be a minor optimization.  I don't see any reason not to expose it as public; the javadoc for the constructor is clear about the proper usage.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 14:58:33 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 14:58:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1115) Modifications
 to list
 objects contained within a bean and carried out during the execution of a
 rule are not reflected in the original list i.e. the changes are lost
 between the instance available within the rule  and that of the original
 bean
In-Reply-To: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9343535.1187981913377.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1115?page=comments#action_12373750 ] 
            
Edson Tirelli commented on JBRULES-1115:
----------------------------------------

Ok, I did some debugging and the problem is indeed related to ShadowFacts. Let me first show you my tests:

    public void testShadowProxyOnCollections() throws Exception {
        final PackageBuilder builder = new PackageBuilder();
        builder.addPackageFromDrl( new InputStreamReader( getClass().getResourceAsStream( "test_ShadowProxyOnCollections.drl" ) ) );
        final Package pkg = builder.getPackage();

        final RuleBase ruleBase = getRuleBase();
        ruleBase.addPackage( pkg );
        final WorkingMemory workingMemory = ruleBase.newStatefulSession();

        final List results = new ArrayList();
        workingMemory.setGlobal( "results",
                                 results );

        final Cheesery cheesery = new Cheesery();
        workingMemory.insert( cheesery );

        workingMemory.fireAllRules();

        assertEquals( 1,
                      results.size() );
        assertEquals( 1, 
                      cheesery.getCheeses().size() );
        assertEquals( results.get( 0 ), 
                      cheesery.getCheeses().get( 0 ) );
    }

If we use the following rule, there is no problem, since in the consequence, we unwrap the shadow proxy, and what you get is your original object, where the Cheese is correctly added to the Cheesery object.

package org.drools;
global java.util.List results;

rule "shadow proxy on collections"
	when
		$c : Cheesery()
	then
	    Cheese cheese = new Cheese( "stilton", 10 );
		$c.addCheese( cheese );
		results.add( cheese );
end

Now, if we use "collect" to create a list, like in the following rule, what is added to the list is the object with the shadow proxy wrapper. So, when it is extracted from the list, you are using the shadow proxy and not the original object. There would be no serious problem if you were not using a getXXX() method, because all other non-final methods are delegated... only get methods are shadowed, and so, the getCheeses() method is returning the shadowed collection instead of the original collection:

rule "shadow proxy on collections"
	when
		$list : ArrayList() from collect( Cheesery() )
	then
	    Cheesery $c = (Cheesery) $list.get( 0 );
	    Cheese cheese = new Cheese( "stilton", 10 );
		$c.getCheeses().add( cheese );
		results.add( cheese );
end

So, if instead of getting the collection and add the cheese, a addCheese() method was created into the Cheesery class, if would correctly delegate and add the object to the correct collection:

rule "shadow proxy on collections"
	when
		$c : Cheesery()
	then
	    Cheese cheese = new Cheese( "stilton", 10 );
		$c.addCheese( cheese );
		results.add( cheese );
end

Although, I know this "workaround" is not correct because shadow proxies should not be exposed to custom user code like the consequence. What I'm not sure about is how we can ensure no shadow proxy is exposed if we allow any arbitrary code to be used in semantic code blocks like consequence and accumulate actions... 

Probably we will need to catch known declarations like collect declarations and pre-process them in the consequence, extracting shadow proxies, to avoid such behavior?


> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1115
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: HP-UX  java version "1.5.0.05"
>            Reporter: Anthony Dawson
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> During the execution of the rules when I modify a list my changes are not reflected in my bean. 
> Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.
> Details of this problem are described in the forum messages.
> http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 15:00:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 15:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7784622.1187982018368.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=comments#action_12373751 ] 
            
Edson Tirelli commented on JBRULES-1060:
----------------------------------------

Can we close this issue? Is a OOME you are getting?


> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Fri Aug 24 15:00:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 15:00:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1060) Unexpected exit
 with no stack trace or other information
In-Reply-To: <7623127.1186367389364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27815105.1187982018559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1060?page=all ]

Edson Tirelli updated JBRULES-1060:
-----------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Unexpected exit with no stack trace or other information
> --------------------------------------------------------
>
>                 Key: JBRULES-1060
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1060
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340,  JBOSS Rules feature/plugin 4.0.0
>            Reporter: christopher barham
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>         Attachments: strangeExit.zip
>
>
> When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information.  I pared down my code to a simple example that demonstrates this below.  I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit.  I am running this from Eclipse.
> Garbage.java (fact bean):
> package com.sample;
> public class Garbage {
>     private char id;
>     private int someNumber;
>     public Garbage(char garbageId, int someNumber) {
>         setSomeNumber(someNumber);
>         setId(garbageId);
>     }
>     public char getId() {
>         return id;
>     }
>     public int getSomeNumber() {
>         return someNumber;
>     }
>     public void setId(char id) {
>         this.id = id;
>     }
>     public void setSomeNumber(int someNumber) {
>         this.someNumber = someNumber;
>     }
>     @Override
>     public String toString() {
>         StringBuilder sb = new StringBuilder();
>         sb.append("a Garbage { ");
>         sb.append("someNumber= ");
>         sb.append(getSomeNumber());
>         sb.append(", id= ");
>         sb.append(getId());
>         sb.append(" }");
>         return sb.toString();
>     }
> }
> StrangeExit.Java (Rule Engine startup and fact insertion):
> package com.sample;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.event.DebugWorkingMemoryEventListener;
> import org.drools.rule.Package;
> public class StrangeExit {
>     public static final void main(String[] args) {
>         try {
>             long startTime = System.currentTimeMillis();
>             System.out.println("Starting problem at " + new java.util.Date());
>             RuleBase ruleBase = readRule();
>             WorkingMemory workingMemory = ruleBase.newStatefulSession();
>             workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
>             assertAllFacts(workingMemory);
>             workingMemory.fireAllRules();
>             long stopTime = System.currentTimeMillis();
>             long runTime = stopTime - startTime;
>             System.out.println("Run time (milliseconds): " + runTime);
>             System.out.println("Finished problem at " + new java.util.Date());
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
>     private static void assertAllFacts(WorkingMemory workingMemory) {
>         for (int i = 1; i <= 3; i++) {
>             for (int j = 1; j <= 475; j++) {
>                 Garbage gar = new Garbage((char)(i + 64), j);
>                 workingMemory.insert(gar);
>             }
>         }
>     }
>     private static RuleBase readRule() throws Exception {
>         Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(source);
>         Package pkg = builder.getPackage();
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         ruleBase.addPackage(pkg);
>         return ruleBase;
>     }
> }
> The Rule itself:
> package com.sample
> import com.sample.Garbage;
> rule "Weird exit with no stack trace error"
>   when
>     $garA : Garbage(  )
>     $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
>   then
>     System.out.println("Something is up");
> 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 lists.jboss.org  Fri Aug 24 15:08:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 15:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4627) Move to JGroups 2.5
Message-ID: <11378851.1187982498232.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move to JGroups 2.5
-------------------

                 Key: JBAS-4627
                 URL: http://jira.jboss.com/jira/browse/JBAS-4627
             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-5.0.0.Beta3


JGroups 2.5.0.GA is out.  AS 5 must use this release or later.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 15:10:21 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 15:10:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4628) Update multiplexer
 protocol stack configs for 2.5
Message-ID: <16779250.1187982621551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update multiplexer protocol stack configs for 2.5
-------------------------------------------------

                 Key: JBAS-4628
                 URL: http://jira.jboss.com/jira/browse/JBAS-4628
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For:  JBossAS-5.0.0.Beta3


Configure concurrent tack; get rid of deprecated properties, 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 lists.jboss.org  Fri Aug 24 16:04:35 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:04:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-408) Figure out a way
 to use alternate pom files in modules.
Message-ID: <1559246.1187985875287.JavaMail.jira@cloud.prod.atl2.jboss.com>

Figure out a way to use alternate pom files in modules.
-------------------------------------------------------

                 Key: JBBUILD-408
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-408
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Currently the jdk14 builds have to be done as separate modules, because maven is not able to use alternate files (pom-jdk14.xml) in modules.
This issue has been created to address this in maven: http://jira.codehaus.org/browse/MNG-3150
Until this issue is resolved, maybe an ant script can be created to build the modules as an aggregate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 16:04:35 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:04:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-408) Figure out a way
 to use alternate pom files in modules.
In-Reply-To: <1559246.1187985875287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19096071.1187985875417.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-408?page=all ]

Paul Gier reassigned JBBUILD-408:
---------------------------------

    Assignee: Paul Gier

> Figure out a way to use alternate pom files in modules.
> -------------------------------------------------------
>
>                 Key: JBBUILD-408
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-408
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Currently the jdk14 builds have to be done as separate modules, because maven is not able to use alternate files (pom-jdk14.xml) in modules.
> This issue has been created to address this in maven: http://jira.codehaus.org/browse/MNG-3150
> Until this issue is resolved, maybe an ant script can be created to build the modules as an aggregate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 16:10:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-409) Fix microcontainer
	jdk14 tests.
Message-ID: <12323051.1187986218403.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix microcontainer jdk14 tests.
-------------------------------

                 Key: JBBUILD-409
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-409
             Project: JBoss Build System
          Issue Type: Task
          Components: JBossRetro, Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Many of the retro build tests for microcontainer are failing.  These are mostly caused by missing features of jboss-retro.  Once the relevant retro issues have been resolved, the tests should be checked again to find remaining 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 lists.jboss.org  Fri Aug 24 16:10:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1039) Optimized
 replication of entities and extended persistence context in SFSBs
Message-ID: <29571265.1187986218521.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimized replication of entities and extended persistence context in SFSBs
---------------------------------------------------------------------------

                 Key: EJBTHREE-1039
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1039
             Project: EJB 3.0
          Issue Type: Feature Request
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry


Optimize replication of clustered SFSBs that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held by the SFSB and those held by the replicated EntityManager.

Currently object identity is maintained by serializing the SFSB and the related EntityManager in one operation. The entire EM is serialized, including entities that have been flushed to the db.  This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.

Intent is to:
1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
2) When writing the fields in an SFSB, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
5) SFSBs should be lazy-deserialized (i.e. only deserialize if needed to handle failover).  This is the way SFSBs clustering already works.  This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.

Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer".  If registered, implementation of many of the steps above would be delegated.  JBoss Seam would intend to register an 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 lists.jboss.org  Fri Aug 24 16:16:29 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 16:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-410) Set up retro
 jdk1.4 build and test of microcontainer on hudson.
Message-ID: <17193616.1187986589124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Set up retro jdk1.4 build and test of microcontainer on hudson.
---------------------------------------------------------------

                 Key: JBBUILD-410
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-410
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


A retro build of microcontainer should be set up on hudson so that we can see which tests are failing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 16:18:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4629) Optimized
 replication of entities
 and extended persistence context in HttpSessions
Message-ID: <2279651.1187986698489.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimized replication of entities and extended persistence context in HttpSessions
----------------------------------------------------------------------------------

                 Key: JBAS-4629
                 URL: http://jira.jboss.com/jira/browse/JBAS-4629
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry


Optimize replication of clustered web sessions that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held as a session attribute and those held by the replicated EntityManager.

Currently object identity is maintained by serializing the entire session as one operation (and thus only works reliably if SESSION granularity is used). The entire EM is serialized, including entities that have been flushed to the db. This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.

Intent is to:
1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
2) When writing the attributes in the session, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
5) Sessions should be lazy-deserialized (i.e. only deserialize if needed to handle failover). This is the way web session clustering already works. This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.

Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer". If registered, implementation of many of the steps above would be delegated. JBoss Seam would intend to register an 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 lists.jboss.org  Fri Aug 24 16:20:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1039) Optimized
 replication of entities and extended persistence context in SFSBs
In-Reply-To: <29571265.1187986218521.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12507279.1187986818225.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1039?page=comments#action_12373765 ] 
            
Brian Stansberry commented on EJBTHREE-1039:
--------------------------------------------

EJBTHREE-1039 and JBAS-4629 involve the same concepts applied to SFSBs and HttpSessions, respectively.

> Optimized replication of entities and extended persistence context in SFSBs
> ---------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1039
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1039
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> Optimize replication of clustered SFSBs that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held by the SFSB and those held by the replicated EntityManager.
> Currently object identity is maintained by serializing the SFSB and the related EntityManager in one operation. The entire EM is serialized, including entities that have been flushed to the db.  This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.
> Intent is to:
> 1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
> 1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
> 2) When writing the fields in an SFSB, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
> 3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
> 4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
> 5) SFSBs should be lazy-deserialized (i.e. only deserialize if needed to handle failover).  This is the way SFSBs clustering already works.  This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.
> Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer".  If registered, implementation of many of the steps above would be delegated.  JBoss Seam would intend to register an 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 lists.jboss.org  Fri Aug 24 16:29:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Aug 2007 16:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4630) Coordinate optimized
 entity/XPC replication across web and ejb3 tiers
Message-ID: <18148510.1187987358480.JavaMail.jira@cloud.prod.atl2.jboss.com>

Coordinate optimized entity/XPC replication across web and ejb3 tiers
---------------------------------------------------------------------

                 Key: JBAS-4630
                 URL: http://jira.jboss.com/jira/browse/JBAS-4630
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering, EJB3, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry


See EJBTHREE-1039 and JBAS-4629 for background.

For use cases that involve requests that store entities and XPCs in both the web and ejb3 tiers, need to ensure that the process is properly handled.

At minimum, need to ensure that the XPC is always deserialized before any managed entities, no matter what the access pattern is.

It would also be nice to avoid duplicate serialization of the XPC.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 17:36:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-406) Create retro build
	for aop
In-Reply-To: <1127269.1187729719337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6188043.1187991378633.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-406?page=all ]

Paul Gier closed JBBUILD-406.
-----------------------------

    Resolution: Done

AOP now has a basic retro build in place.
The rest will be completed when the general aop mavenization is complete.

> Create retro build for aop
> --------------------------
>
>                 Key: JBBUILD-406
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-406
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> AOP needs a retro 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 lists.jboss.org  Fri Aug 24 17:40:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-93) Add JBossRetro
 builds for Microcontainer projects
Message-ID: <15705701.1187991618365.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=all ]

Paul Gier closed JBMICROCONT-93.
--------------------------------

    Resolution: Done

The basic retro builds and tests are now in place.  I created new issues for setting up hudson builds, and for resolving the remaining issues with the tests.
Due to a limitation in maven, the retro modules have to be built individually instead of as an aggregated project.  I will try to get this issue resolved in an upcoming release of maven.

> Add JBossRetro builds for Microcontainer projects
> -------------------------------------------------
>
>                 Key: JBMICROCONT-93
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93
>             Project: JBoss MicroContainer
>          Issue Type: Sub-task
>          Components: General
>            Reporter: Adrian Brock
>         Assigned To: Paul Gier
>             Fix For: JBossMC-2.0.0.CR1
>
>
> Make JBossRetro builds for the microcontainer projects
> such that they can use JDK5 features.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 17:43:31 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:43:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-407) Migrate
 microcontainer docbook gen to jdocbook plugin
In-Reply-To: <26415361.1187899278199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10547195.1187991811918.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-407?page=all ]

Paul Gier reassigned JBBUILD-407:
---------------------------------

    Assignee: Paul Gier

> Migrate microcontainer docbook gen to jdocbook plugin
> -----------------------------------------------------
>
>                 Key: JBBUILD-407
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-407
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Microcontainer should use the maven-jdocbook-plugin for it's doc generation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 17:57:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Aug 2007 17:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-203) Analyze
 microcontainer dependencies
Message-ID: <19082098.1187992638420.JavaMail.jira@cloud.prod.atl2.jboss.com>

Analyze microcontainer dependencies
-----------------------------------

                 Key: JBMICROCONT-203
                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-203
             Project: JBoss MicroContainer
          Issue Type: Task
          Components: General
            Reporter: Paul Gier
         Assigned To: Paul Gier
             Fix For: JBossMC-2.0.0.CR1


Using the mvn dependency plugin "mvn dependency:analyze", I noticed that several of the microcontainer modules are using transitive dependencies directly and/or are listing dependencies that aren't used.  This dependency tool should be used to clean up these dependencies a bit to make it more clear which ones are required for compilation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:10:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 18:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1121) Operator field
 and the fact's
 variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26950896.1187993418624.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=all ]

Mark Proctor updated JBRULES-1121:
----------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms, Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:10:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 24 Aug 2007 18:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1114) Rule
 compilation not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6605441.1187993418926.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1114?page=comments#action_12373780 ] 
            
Edson Tirelli commented on JBRULES-1114:
----------------------------------------

Ok, we found the error in the template engine we are using for code generation. Working on the fix.

> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:10:19 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Fri, 24 Aug 2007 18:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29897339.1187993419090.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373781 ] 
            
Michael Neale commented on JBRULES-1121:
----------------------------------------

in the "then" part - if you put an "=" at the start (a bit like in excel) you can do a calculation (it won't be a text field). 

Is that what you want? 

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms, Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:25:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1032) inconsistent
 results for
 CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
In-Reply-To: <32360816.1187381960564.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17435867.1187994318254.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1032?page=all ]

William DeCoste closed EJBTHREE-1032.
-------------------------------------

    Fix Version/s: AS 4.2.2.GA
                   Branch_4_2
       Resolution: Done

> inconsistent results for CreateCount, AvailableCount, CurrentSize for StrictMaxPool SLSBs
> -----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1032
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1032
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1, AS 4.2.0 GA, AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.GA, Branch_4_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 lists.jboss.org  Fri Aug 24 18:37:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1040) add flag to
 improve
 deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
Message-ID: <18074307.1187995038327.JavaMail.jira@cloud.prod.atl2.jboss.com>

add flag to improve deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
--------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1040
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1040
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: AS 4.2.1.GA
            Reporter: William DeCoste
         Assigned To: William DeCoste
            Priority: Minor


Currently all jar/ejb3 files are scanned for the existence of annotated classes. This can cause slow deployment times. Create a switch with flag for only deploying jar/ejb3 files with either/or a ejb-jar.xml or jboss.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 lists.jboss.org  Fri Aug 24 18:39:22 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:39:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22610176.1187995162287.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12373785 ] 
            
William DeCoste commented on EJBTHREE-1025:
-------------------------------------------

The above construct should throw an EJBException at deployment time.

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:39:22 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:39:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17028678.1187995162484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=all ]

William DeCoste updated EJBTHREE-1025:
--------------------------------------

    Comment: was deleted

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 18:41:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Fri, 24 Aug 2007 18:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18953643.1187995278571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=all ]

William DeCoste updated EJBTHREE-1025:
--------------------------------------

    Description: 
The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

There is a test for this construct in Branch_4_2.

  was:
The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}


> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> The following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}
> There is a test for this construct in Branch_4_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 lists.jboss.org  Fri Aug 24 19:04:18 2007
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Fri, 24 Aug 2007 19:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4611) HTTP Session Repl
 Cache configured with CacheLoader can cause slow AS shutdowns
In-Reply-To: <26411619.1187251081159.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21936881.1187996658288.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4611?page=comments#action_12373789 ] 
            
Jimmy Wilson commented on JBAS-4611:
------------------------------------

Switching the invocation order made no difference as getChildrenNames still went remote.

> HTTP Session Repl Cache configured with CacheLoader can cause slow AS shutdowns
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-4611
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4611
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering, JBoss Cache
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> When AS stops, the sessions for that web app are evicted from memory, 
> which means removing from the memory locally. We still need the sessions
>  in other nodes, for example if we're bringing a node down for maintenance 
> in which case, we don't want to remove sessions of the cluster completely. 
> We want users to failover to another node and continue as normal.
> The code handling this evictions first removes any data in these sessions and
>  then tries to check whether this HTTP session has any children nodes in the
>  cache so that it can do a complete clearout of the subtree:
> JBossCacheWrapper:
>    void evictSubtree(Fqn fqn)
>    {
>       Exception ex = null;
>       for (int i = 0; i < RETRY; i++)
>       {
>          try
>          {
>             // Evict the node itself first, since if it stores a Pojo
>             // that will do everything
>             proxy_.evict(fqn);
>             // next do a depth first removal; this ensure all nodes
>             // are removed, not just their data map
>             Set children = proxy_.getChildrenNames(fqn);
> ...
> If no cache loaders were used, this would be fine, it wouldn't find any 
> children in memory and would return quickly. A true local call. 
> However, for a customer who's using a ClusteredCacheLoader to get around 
> some state transfer issues, when AS discovers that this session does 
> not contain any children nodes, it goes remote to find them because 
> it didn't find them locally (won't find them remotely either):
> CacheLoaderInterceptor:
>    private boolean mustLoad(DataNode n, Object key)
>    {
>       return n == null ||
>               (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key)));
>    }
> As the node has been emptied, CLI (CacheLoaderInterceptor) thinks it 
> needs to go remote. Same thing would happen with Pojo too (as the 
> entire node is emptied). This is an unnecessary trip which is delaying 
> the local eviction of sessions.
> This would happen regardless of the CacheLoader used.
> Two possible solutions come to my mind:
> - easy one: call getChildrenNames() before evict and cache in a local variable the 
> children Set. getChildrenNames() would land locally cos the fqn exists yet.
> - complex one: do a getChildrenNames(Option) passing an option indicating that 
> if the lookup fails locally, don't bother going remote.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 19:26:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 19:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1106) Copied rules
 using a guided
 DSL in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18256668.1187997978905.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1106?page=all ]

Fernando Meyer reassigned JBRULES-1106:
---------------------------------------

    Assignee: Fernando Meyer  (was: Michael Neale)

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 19:31:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 19:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1106) Copied rules using
 a guided DSL
 in BRMS produce duplicate rule names in built binary packages.
In-Reply-To: <20296613.1187692638579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25426170.1187998278295.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1106?page=all ]

Fernando Meyer closed JBRULES-1106.
-----------------------------------

    Resolution: Done

missing copy step was added to handle with brxml assets 

> Copied rules using a guided DSL in BRMS produce duplicate rule names in built binary packages.
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1106
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1106
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP SP2, Sun JRE 1.5_09
>            Reporter: Shahad Ahmed
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> I found the following problem when creating rules using the guided rule editor in the BRMS with a DSL. If you use the copy option to copy an existing rule, everything seems okay and a new copy of the rule is created in the package. However, if you build the package and view the package source then any rule that was copied from another rule has the same name as the original rule. Consequently your rule package has rules with the same name and will throw an error when loaded into a rulebase. Note this problem does not appear to occur if you do not use a DSL.
> Here's how to replicate the problem for a clean BRMS install:
> 1. Create a new category called test.
> 2. In the defaultPackage create a new DSL called test as shown below:
> [when]true=eval(true)
> [then]report=System.out.println("Hello");
> 3. Save the test DSL
> 4. Create a new Business Rule in the defaultPackage called test1 with category test and using the guided rule editor.
> 5 Add a when expression using the DSL sentence "true" and add a then action using the DSL sentence "report". In the rule option, add the dialect attribute and set it to "java".
> 6. Save rule test1.
> 7. Click on the Copy tab to copy test1. Name the new rule test2. You will see a dialog that confirms the creation of rule test2.
> 8. Open rule test2 from the rule browser and it seems okay and has the name test2 (minor funny is that test2 has version 2, whereas test1 only has version 1).
> 9. Select the package option on the left of the BRMS and select the defaultPackage so that you see the "Build, Validate and Deploy" option. Select this and build the package.
> 10 Now click on the Show Package Source button and you will see two rules both named test1 (as shown below) instead of two rules named test1 and test2 as expected. This package is incorrect, even though the rules in the BRMS seem to correctly have names test1 and test2. I can confirm that trying to load the exported binary package into a rulebase cause an error to be reported (so it's not just a bug in the show package source code, but in the generated binary as well).
> package defaultPackage
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> rule "test1"
> 	dialect "java"
> 	when
> 	eval(true)
> 	then
> 	System.out.println("Hello");
> end
> Shahad

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 19:53:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Aug 2007 19:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
Message-ID: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>

DistributedTopicTest::testClusteredTopicDurablePersistent fails
---------------------------------------------------------------

                 Key: JBMESSAGING-1059
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR1
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
            Priority: Blocker
             Fix For: 1.4.0.CR2


Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...

There is an patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Fri Aug 24 19:55:46 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Aug 2007 19:55:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
In-Reply-To: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5360919.1187999746598.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1059?page=all ]

Clebert Suconic updated JBMESSAGING-1059:
-----------------------------------------

    Attachment: jbmessaging-1059.patch

> DistributedTopicTest::testClusteredTopicDurablePersistent fails
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1059
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>         Attachments: jbmessaging-1059.patch
>
>
> Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...
> There is an patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Fri Aug 24 19:55:46 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Aug 2007 19:55:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
In-Reply-To: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16797082.1187999746755.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1059?page=all ]

Clebert Suconic updated JBMESSAGING-1059:
-----------------------------------------

    Description: 
Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...

There is a patch attached for a probable fix on the test.. but I want to investigate this before committing the patch.

  was:
Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...

There is an patch attached for a probable fix on the test.. but I want to investigate this before committing the patch.


> DistributedTopicTest::testClusteredTopicDurablePersistent fails
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1059
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>         Attachments: jbmessaging-1059.patch
>
>
> Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...
> There is a patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Fri Aug 24 20:31:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1123) Custom
 Consequence Exception handlers
Message-ID: <1209026.1188001878202.JavaMail.jira@cloud.prod.atl2.jboss.com>

Custom Consequence Exception handlers
-------------------------------------

                 Key: JBRULES-1123
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1123
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 4.0.1


RuleBaseConfiguration should allow the user to specify a custom handler for consequence exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:33:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1123) Custom
 Consequence Exception handlers
In-Reply-To: <1209026.1188001878202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16456013.1188001998208.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1123?page=comments#action_12373795 ] 
            
Mark Proctor commented on JBRULES-1123:
---------------------------------------

users can now use the property "drools.consequenceExceptionHandler" or the RuleBaseconfiguration.setConsequenceExceptionHandler to specify a custom user defined handler for consequence exceptions.

> Custom Consequence Exception handlers
> -------------------------------------
>
>                 Key: JBRULES-1123
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1123
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> RuleBaseConfiguration should allow the user to specify a custom handler for consequence exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:35:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1123) Custom Consequence
 Exception handlers
In-Reply-To: <1209026.1188001878202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29816719.1188002118233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1123?page=all ]

Mark Proctor closed JBRULES-1123.
---------------------------------

    Resolution: Done

> Custom Consequence Exception handlers
> -------------------------------------
>
>                 Key: JBRULES-1123
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1123
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> RuleBaseConfiguration should allow the user to specify a custom handler for consequence exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:54:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-851) Provide RuleFlow
 editing capabilities within JBRMS
In-Reply-To: <10955939.1179153237844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33358412.1188003258390.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-851?page=comments#action_12373798 ] 
            
Mark Proctor commented on JBRULES-851:
--------------------------------------

I believe you can already handle ruleflow as assets in the BRMS.

> Provide RuleFlow editing capabilities within JBRMS
> --------------------------------------------------
>
>                 Key: JBRULES-851
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-851
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Anstis
>         Assigned To: Mark Proctor
>
> Ruleflow should be available in the JBRMS (apologies is this JIRA should have been raised against JBRMS).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:56:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1122) Eclipse-JDT
 compiler jar
 (core-3.2.0.666.jar) for drools creates problems/conflicts with the
 existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
In-Reply-To: <527189.1187948822233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8734018.1188003378277.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1122?page=all ]

Mark Proctor closed JBRULES-1122.
---------------------------------

    Resolution: Rejected

The is already covered here http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesTomcat

> Eclipse-JDT compiler jar (core-3.2.0.666.jar) for drools creates problems/conflicts with the existing one (jasper-compiler-jdt.jar - used by tomcat for JSP compilation)
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1122
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1122
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.6,  4.0.0.GA
>         Environment: Windows XP / JDK 1.5.0_06-b05
>            Reporter: Suman Ghosh
>         Assigned To: Mark Proctor
>
> I'm running a service using JBoss, which uses Drools for its various rule-based components. The propblem arises like this -  when I use the JDTcompiler in Drools, tomcat crashes with the following stacktrace (when used to access JSPs - such as the JBoss JMX console)....
> ----------------------------------------------------START-------------------------------------------------------------------
> type Exception report
> message
> description The server encountered an internal error () that prevented it from fulfilling this request.
> exception
> javax.servlet.ServletException: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
> 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:272)
> 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> root cause
> java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
> 	org.apache.jasper.compiler.JDTCompiler$2.acceptResult(JDTCompiler.java:345)
> 	org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417)
> 	org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:404)
> 	org.apache.jasper.compiler.Compiler.compile(Compiler.java:297)
> 	org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
> 	org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
> 	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
> 	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303)
> 	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
> 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
> 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
> ---------------------------------------------------END--------------------------------------------------------------------
> Seems that the class CompilationResult from the new JDT distribution has a different signature for the getProblems() method - but tomcat expects the earlier one only.
> For my application, I *have* to use the JDT compiler for my rule base, and on the other hand, I require the jboss jmx-console, for service monitoring and method invokations :(
> Please suggest a solution!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 20:58:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 20:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-851) Provide RuleFlow
 editing capabilities within JBRMS
In-Reply-To: <10955939.1179153237844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20038791.1188003498272.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-851?page=comments#action_12373801 ] 
            
Mark Proctor commented on JBRULES-851:
--------------------------------------

or where you talking about actually editing ruleflows in the BRMS? Not sure how we would do that, dhtml doesn't handle graphs well. We would have to look into building an SVG system, or figure  out how to webstate an RCP version of the Eclipse IDE.

> Provide RuleFlow editing capabilities within JBRMS
> --------------------------------------------------
>
>                 Key: JBRULES-851
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-851
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Anstis
>         Assigned To: Mark Proctor
>
> Ruleflow should be available in the JBRMS (apologies is this JIRA should have been raised against JBRMS).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 21:05:18 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Fri, 24 Aug 2007 21:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-851) Provide RuleFlow
 editing capabilities within JBRMS
In-Reply-To: <10955939.1179153237844.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12344179.1188003918351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-851?page=all ]

Fernando Meyer reassigned JBRULES-851:
--------------------------------------

    Assignee: Fernando Meyer  (was: Mark Proctor)

> Provide RuleFlow editing capabilities within JBRMS
> --------------------------------------------------
>
>                 Key: JBRULES-851
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-851
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Anstis
>         Assigned To: Fernando Meyer
>
> Ruleflow should be available in the JBRMS (apologies is this JIRA should have been raised against JBRMS).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 21:55:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 21:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1124) Code completion
 does not work for 'with' blocks
Message-ID: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>

Code completion does not work for 'with' blocks
-----------------------------------------------

                 Key: JBRULES-1124
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 21:57:30 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 21:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13259892.1188007050763.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1124?page=all ]

Mark Proctor updated JBRULES-1124:
----------------------------------

    Attachment: withCodeCompletion.JPG

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 22:11:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1125) Java Step over is
	broken
Message-ID: <26835535.1188007878253.JavaMail.jira@cloud.prod.atl2.jboss.com>

Java Step over is broken
------------------------

                 Key: JBRULES-1125
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1125
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


Java Step Over is broken. I put in a break point and I can't step through the 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 lists.jboss.org  Fri Aug 24 22:15:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1126) Step over in MVEL
	is broken
Message-ID: <33412742.1188008118280.JavaMail.jira@cloud.prod.atl2.jboss.com>

Step over in MVEL is broken
---------------------------

                 Key: JBRULES-1126
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1126
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1


cbrock says that step and step-over have been mapped incorrectly. Thus step-over does not work with MVEL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 24 22:19:24 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1127) External vars do
 not appear if you hve a break point on the first line
Message-ID: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>

External vars do not appear if you hve a break point on the first line
----------------------------------------------------------------------

                 Key: JBRULES-1127
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1
         Attachments: debugvars1.jpg, debugvars2.jpg

if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Fri Aug 24 22:19:25 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Fri, 24 Aug 2007 22:19:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1127) External vars do
 not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9178690.1188008365088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=all ]

Mark Proctor updated JBRULES-1127:
----------------------------------

    Attachment: debugvars1.jpg
                debugvars2.jpg

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 00:34:18 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Sat, 25 Aug 2007 00:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4593) Leak in
 org/jboss/mx/loading/UnifiedClassLoader3
In-Reply-To: <2354196.1186435489333.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16432107.1188016458492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4593?page=all ]

Scott M Stark resolved JBAS-4593.
---------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                   JBossAS-4.2.2.GA
       Resolution: Done

Added a org.jboss.mx.loading.UnifiedLoaderRepository.notifyMode system property that controls how whether a jmx notification is sent, if done, whether the class loader is wrapped in a WeakReference. It should be set to one of 0, 1 or 2:
   // Send notification with the ClassLoader as the user data
   private static int LEGACY_MODE = 0;
   // Send notification with the ClassLoader as the user data wrapped in a WeakReference
   private static int WEAK_REFERENCE_MODE = 1;
   // Don't send any notifications
   private static int NO_NOTIFICATION_MODE = 2;

The default is the LEGACY_MODE.


> Leak in org/jboss/mx/loading/UnifiedClassLoader3
> ------------------------------------------------
>
>                 Key: JBAS-4593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Scott M Stark
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> [description pasted from support case]
> After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:
> found a path to the target: 26093 (depth: 5)
> 0 0 Heap root
> 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
> 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
> 160611 0 Instance: [Ljava/lang/Object;
> 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
> 217357 0 Instance: Ljavax/management/Notification;
> 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;
> So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.
> Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 07:36:18 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Sat, 25 Aug 2007 07:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-691) Decision class does
 not allow setting of Decision Delegation
In-Reply-To: <31453146.1152625331489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4181973.1188041778297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-691?page=all ]

Ronald van Kuijk updated JBPM-691:
----------------------------------

    Priority: Minor  (was: Major)

Why not just write a patch for the source instead of this 'workaround'? That patch can be included then in jbpm (if the developers agree)

> Decision class does not allow setting of Decision Delegation
> ------------------------------------------------------------
>
>                 Key: JBPM-691
>                 URL: http://jira.jboss.com/jira/browse/JBPM-691
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions: jBPM 3.1.1
>         Environment: Windows XP
> MySQL
> WSAD 5.1.2
>            Reporter: Chris OBrien
>         Assigned To: Tom Baeyens
>            Priority: Minor
>
> In programmatically creating/manipulating a process definition, one cannot specify a Decision Delegation on a Decision node.
> The Decision class just needs a method like:
>   public void setDecisionDelegation( Delegation del ) {
> 	  this.decisionDelegation = del;
>   }
> I have added this to my install, and it allows me to programmatically change the process definition to define the handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:08:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 08:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1126) Step over in
	MVEL is broken
In-Reply-To: <33412742.1188008118280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24268257.1188043698293.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1126?page=comments#action_12373825 ] 
            
Mark Proctor commented on JBRULES-1126:
---------------------------------------

When placing a breakpoint on the first line of the hello world example. It would stop ok, I would press step-over and it would show this error:
org.mvel.PropertyAccessException: unable to resolve property: ;
	at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:287)
	at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109)
	at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:182)
	at org.mvel.MVELRuntime.execute(MVELRuntime.java:85)
	at org.mvel.MVEL.executeDebugger(MVEL.java:344)
	at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:39)

cbrock says this is because mvel has both step and step-over and you really want to use mvel step, or something like that.

> Step over in MVEL is broken
> ---------------------------
>
>                 Key: JBRULES-1126
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1126
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> cbrock says that step and step-over have been mapped incorrectly. Thus step-over does not work with MVEL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:31:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1128) Xstream should be
 optional for drools-core and it should use the non-legacy groupId
Message-ID: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>

Xstream should be optional for drools-core and it should use the non-legacy groupId 
------------------------------------------------------------------------------------

                 Key: JBRULES-1128
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
             Project: JBoss Rules
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
             Fix For: FUTURE



        <!-- Xstream -->
        <dependency>
            <groupId>com.thoughtworks.xstream</groupId>
            <artifactId>xstream</artifactId>
            <version>1.2.2</version>
        </dependency>



        <!-- Xstream -->
        <dependency>
            <groupId>com.thoughtworks.xstream</groupId>
            <artifactId>xstream</artifactId>
            <optional>true</optional><!-- Only needed for auditing -->
        </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:35:22 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:35:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1128) Xstream should
 be optional for drools-core and it should use the non-legacy groupId
In-Reply-To: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28893281.1188045322248.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1128?page=comments#action_12373826 ] 
            
Geoffrey De Smet commented on JBRULES-1128:
-------------------------------------------

Being non optional and having the non-legacy groupId it caused some classpath havoc in taseree.

> Xstream should be optional for drools-core and it should use the non-legacy groupId 
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1128
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
>             Project: JBoss Rules
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>             Fix For: FUTURE
>
>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <version>1.2.2</version>
>         </dependency>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <optional>true</optional><!-- Only needed for auditing -->
>         </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 08:49:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27811770.1188046158660.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-992?page=all ]

Geoffrey De Smet reassigned JBRULES-992:
----------------------------------------

    Assignee: Geoffrey De Smet  (was: Mark Proctor)

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Sat Aug 25 08:55:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 08:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15568019.1188046518254.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-992?page=comments#action_12373827 ] 
            
Geoffrey De Smet commented on JBRULES-992:
------------------------------------------

 <conan> ge0ffrey: just add the information to the dependencies README docs.


> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Sat Aug 25 10:33:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sat, 25 Aug 2007 10:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1115) Modifications to
 list objects
 contained within a bean and carried out during the execution of a rule are
 not reflected in the original list i.e. the changes are lost  between the
 instance available within the rule  and that of the original bean
In-Reply-To: <28054582.1187875938478.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27396613.1188052398735.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1115?page=all ]

Edson Tirelli resolved JBRULES-1115.
------------------------------------

    Resolution: Done

As discussed, I added some controls to unwrap shadow proxies in the case of collection objects created by the collect CE.

Integration test added.

Thank you for reporting and providing test case. Please let us know if you find any other related problem.

Fix will be included in 4.0.1 release.


> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1115
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1115
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: HP-UX  java version "1.5.0.05"
>            Reporter: Anthony Dawson
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Modifications to list objects contained within a bean and carried out during the execution of a rule are not reflected in the original list i.e. the changes are lost  between the instance available within the rule  and that of the original bean
> During the execution of the rules when I modify a list my changes are not reflected in my bean. 
> Changes which affect simple objects like integers, strings etc are modified OK but lists do not get updated in the bean.
> Details of this problem are described in the forum messages.
> http://www.nabble.com/How-to-limit-results-from-a-collect-statement-tf4235669.html#a12278683

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 11:15:18 2007
From: jira-events at lists.jboss.org (Alexandre Russel (JIRA))
Date: Sat, 25 Aug 2007 11:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1141) Redesign
 evictions for greater flexibility
In-Reply-To: <1163240.1184750387057.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10245574.1188054918250.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1141?page=comments#action_12373833 ] 
            
Alexandre Russel commented on JBCACHE-1141:
-------------------------------------------

I hadn't seen that bug sending a patch for the #11. I believe my patch "part answer" this bug as well.
http://jira.jboss.com/jira/browse/JBCACHE-11
alex

> Redesign evictions for greater flexibility
> ------------------------------------------
>
>                 Key: JBCACHE-1141
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1141
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 3.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 lists.jboss.org  Sat Aug 25 12:04:22 2007
From: jira-events at lists.jboss.org (Wolfgang Hollweck (JIRA))
Date: Sat, 25 Aug 2007 12:04:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-1048) Userguide Section
 18.1.1 is
 missleading when describing ant task for deploment of par archive
Message-ID: <26836191.1188057862767.JavaMail.jira@cloud.prod.atl2.jboss.com>

Userguide Section 18.1.1 is missleading when describing ant task for deploment of par archive
---------------------------------------------------------------------------------------------

                 Key: JBPM-1048
                 URL: http://jira.jboss.com/jira/browse/JBPM-1048
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Documentation
    Affects Versions: jBPM jPDL 3.2, jBPM 3.1.4
            Reporter: Wolfgang Hollweck
         Assigned To: Tom Baeyens
            Priority: Minor
             Fix For: jBPM jPDL 3.2, jBPM 3.1.4


Section 18.1.1 in Userguide declares
classname="org.jbpm.ant.DeployParTask"
which does not exist.

It must be called
classname "org.jbpm.ant.DeployProcessTask"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:12:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1129) import does not
 work with code competion
Message-ID: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>

import does not work with code competion
----------------------------------------

                 Key: JBRULES-1129
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
            Priority: Blocker
             Fix For: 4.0.1


imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:14:29 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9275562.1188058469561.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1129?page=comments#action_12373834 ] 
            
Mark Proctor commented on JBRULES-1129:
---------------------------------------

this is worse than I thought. I added a rule and the code completion works, sort of by overwritting the rule.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:16:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32675310.1188058578350.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1129?page=all ]

Mark Proctor updated JBRULES-1129:
----------------------------------

    Attachment: screenshot-1.jpg

here it correctly shows the matching imports.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:18:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33527341.1188058698327.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1129?page=all ]

Mark Proctor updated JBRULES-1129:
----------------------------------

    Attachment: screenshot-2.jpg

This is the screenshot after I select the import, see how it over-writes the rule statement.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:24:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1130) Code completion
 does not work for two char operator symbols
Message-ID: <22006280.1188059058281.JavaMail.jira@cloud.prod.atl2.jboss.com>

Code completion does not work for two char operator symbols
-----------------------------------------------------------

                 Key: JBRULES-1130
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1130
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


When typing the first char of an operator, it does not show you the correct matches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:26:23 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1130) Code completion
 does not work for two char operator symbols
In-Reply-To: <22006280.1188059058281.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3766489.1188059184007.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1130?page=all ]

Mark Proctor updated JBRULES-1130:
----------------------------------

    Attachment: screenshot-1.jpg

Notice here I have selected a single = operator, it should show ==, but shows something totally none relevant.

> Code completion does not work for two char operator symbols
> -----------------------------------------------------------
>
>                 Key: JBRULES-1130
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1130
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> When typing the first char of an operator, it does not show you the correct matches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 12:50:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1131) Errors not
 including line numbers
Message-ID: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>

Errors not including line numbers
---------------------------------

                 Key: JBRULES-1131
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder, Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sat Aug 25 12:52:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24842455.1188060738315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=all ]

Mark Proctor updated JBRULES-1131:
----------------------------------

    Attachment: screenshot-1.jpg

see the from ShoppingCart() is obviously wrong. Its producing an Error, but there are no line numbers and it's not reflected in the outline view.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sat Aug 25 12:54:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 12:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1132) No code
 completion for 'from' expression statements
Message-ID: <28151937.1188060858274.JavaMail.jira@cloud.prod.atl2.jboss.com>

No code completion for 'from' expression statements
---------------------------------------------------

                 Key: JBRULES-1132
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1132
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


If I'm buliding a 'from' statement that is something like from $s.getItems() there is no code completion on that expression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:35:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 15:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1128) Xstream should
 be optional for drools-core and it should use the non-legacy groupId
In-Reply-To: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17742645.1188070518245.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1128?page=comments#action_12373845 ] 
            
Geoffrey De Smet commented on JBRULES-1128:
-------------------------------------------

on irc they said it's ok to upgrade it to the latest version too - which is good for drools-solver which needs at least 1.2.2

> Xstream should be optional for drools-core and it should use the non-legacy groupId 
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1128
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
>             Project: JBoss Rules
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>             Fix For: FUTURE
>
>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <version>1.2.2</version>
>         </dependency>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <optional>true</optional><!-- Only needed for auditing -->
>         </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:43:31 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 15:43:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1128) Xstream should
 be optional for drools-core and it should use the non-legacy groupId
In-Reply-To: <32007794.1188045078253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28747245.1188071011788.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1128?page=all ]

Geoffrey De Smet resolved JBRULES-1128.
---------------------------------------

    Fix Version/s: 4.0.1
                       (was: FUTURE)
       Resolution: Done

done

> Xstream should be optional for drools-core and it should use the non-legacy groupId 
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1128
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1128
>             Project: JBoss Rules
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <version>1.2.2</version>
>         </dependency>
>         <!-- Xstream -->
>         <dependency>
>             <groupId>com.thoughtworks.xstream</groupId>
>             <artifactId>xstream</artifactId>
>             <optional>true</optional><!-- Only needed for auditing -->
>         </dependency>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:51:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Sat, 25 Aug 2007 15:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1239479.1188071478473.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1124?page=comments#action_12373848 ] 
            
Philippe Ombredanne commented on JBRULES-1124:
----------------------------------------------

Could you give a hints? What is a with block?
Where are you trying to complete? after the , and before the closing } ?
What would you expect for completions there?

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 15:51:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Sat, 25 Aug 2007 15:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5968989.1188071478720.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=comments#action_12373849 ] 
            
Philippe Ombredanne commented on JBRULES-1127:
----------------------------------------------

Is this really a major issue?

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 15:51:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 15:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1133) Janino and
 eclipse compiler might need to be optional for 4.1
Message-ID: <3544593.1188071478914.JavaMail.jira@cloud.prod.atl2.jboss.com>

Janino and eclipse compiler might need to be optional for 4.1
-------------------------------------------------------------

                 Key: JBRULES-1133
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1133
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
            Priority: Minor
             Fix For: FUTURE


I didn't want to make this change for 4.0.x as it would require our users to put a direct dependency on either janino or eclipse-compiler.

Drools-compiler needs one of both.
Currently users get bloated with a transitive dependency on both.
Making them optional would force them to make a dependency on one of the themselves... which makes the "hello world" program harder.
As it would also force jbrms's etc tests to choose one.

Why shouldn't do this before 4.1, if we even want to do this.

What do you think?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 16:01:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 16:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-992) Optional
 dependencies not marked as optional in maven pom xmls
In-Reply-To: <27539345.1184047532005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30350384.1188072078447.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-992?page=all ]

Geoffrey De Smet resolved JBRULES-992.
--------------------------------------

    Resolution: Partially Completed

I didn't make janino and eclipse-compiler optional - see JBRULES-1133 as that should be done for a minor (non hotfix) release if it needs to be done in the first case.

> Optional dependencies not marked as optional in maven pom xmls
> --------------------------------------------------------------
>
>                 Key: JBRULES-992
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-992
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.MR3
>         Environment: Maven 2.0.7
>            Reporter: Tuomas Kiviaho
>         Assigned To: Geoffrey De Smet
>             Fix For: 4.0.1
>
>         Attachments: pom.20070725.patch
>
>
> Slimming <http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html> could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>.
> This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. 
> Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation 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 lists.jboss.org  Sat Aug 25 16:18:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1125) Java Step over is
	broken
In-Reply-To: <26835535.1188007878253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22559598.1188073098473.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1125?page=all ]

Ahti Kitsik closed JBRULES-1125.
--------------------------------

    Resolution: Done

change in mvel Debugger interface caused this. Having STEP=STEP_OVER introduces unexpected behaviour in debugging logic (now both step conditions are triggered).

> Java Step over is broken
> ------------------------
>
>                 Key: JBRULES-1125
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1125
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>
> Java Step Over is broken. I put in a break point and I can't step through the 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 lists.jboss.org  Sat Aug 25 16:18:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1125) Java Step over
	is broken
In-Reply-To: <26835535.1188007878253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30120703.1188073098670.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1125?page=comments#action_12373854 ] 
            
Ahti Kitsik commented on JBRULES-1125:
--------------------------------------

sry, this comment was about JBRULES-1126

java step over was broken because of mvel debug implementation (wrong stepover stackframe detection mechanism).

> Java Step over is broken
> ------------------------
>
>                 Key: JBRULES-1125
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1125
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>
> Java Step Over is broken. I put in a break point and I can't step through the 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 lists.jboss.org  Sat Aug 25 16:20:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1126) Step over in MVEL
	is broken
In-Reply-To: <33412742.1188008118280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25908622.1188073218343.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1126?page=all ]

Ahti Kitsik closed JBRULES-1126.
--------------------------------

    Resolution: Done

change in mvel Debugger interface caused this. Having STEP=STEP_OVER introduces unexpected behaviour in debugging logic (now both step conditions are triggered).

> Step over in MVEL is broken
> ---------------------------
>
>                 Key: JBRULES-1126
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1126
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> cbrock says that step and step-over have been mapped incorrectly. Thus step-over does not work with MVEL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 16:20:18 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 25 Aug 2007 16:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1133) Janino and
 eclipse compiler might need to be optional for 4.1
In-Reply-To: <3544593.1188071478914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21161999.1188073218470.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1133?page=comments#action_12373856 ] 
            
Geoffrey De Smet commented on JBRULES-1133:
-------------------------------------------

[22:18] <conan> yes it would be unwise to change it now
[22:18] <conan> people can still exclude
[22:18] <ge0ffrey> in worst case, they can start doing <exclusions>... as this isn't a clear optional dep I 'd leave it like this for now


> Janino and eclipse compiler might need to be optional for 4.1
> -------------------------------------------------------------
>
>                 Key: JBRULES-1133
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1133
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Geoffrey De Smet
>         Assigned To: Geoffrey De Smet
>            Priority: Minor
>             Fix For: FUTURE
>
>
> I didn't want to make this change for 4.0.x as it would require our users to put a direct dependency on either janino or eclipse-compiler.
> Drools-compiler needs one of both.
> Currently users get bloated with a transitive dependency on both.
> Making them optional would force them to make a dependency on one of the themselves... which makes the "hello world" program harder.
> As it would also force jbrms's etc tests to choose one.
> Why shouldn't do this before 4.1, if we even want to do this.
> What do you think?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 16:28:22 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 16:28:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24171428.1188073702598.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=comments#action_12373857 ] 
            
Ahti Kitsik commented on JBRULES-1127:
--------------------------------------

For the reference, this is used in debugger code:

get the list of vars:
return getFactory().getKnownVariables()

get the value for a given varName:
return getVariableResolver(varName).getValue()

Unfortunately I don't have a control to get global vars registered before first line of mvel code is evaluated.
I think it's possible to make this preparation in mvel code (before line=1 breakpoint would be triggered).

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 20:44:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 20:44:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31753171.1188089058278.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1124?page=comments#action_12373860 ] 
            
Mark Proctor commented on JBRULES-1124:
---------------------------------------

mvel has a with block to execute block setters on an object:
with ( object ) { field1 = value1, field2 = expression2 };

We use the macro process on "modify" to change:
modify ( object ) { field1 = value1, field2 = expression2 };

Into this:
@Modify with ( object ) { field1 = value1, field2 = expression2 };

this is the prefered way in Drools and MVEL  to modify facts, as it sets the setters and calls modify in one go.

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 21:04:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 21:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1134) drools variable
 appears twice in context assist
Message-ID: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>

drools variable appears twice in context assist
-----------------------------------------------

                 Key: JBRULES-1134
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1
         Attachments: screenshot-1.jpg

The drools variable appears twice in context compliation, once typed and once as Object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 21:04:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 21:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28439557.1188090258468.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1134?page=all ]

Mark Proctor updated JBRULES-1134:
----------------------------------

    Attachment: screenshot-1.jpg

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Aug 25 21:48:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Sat, 25 Aug 2007 21:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32757081.1188092898299.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=comments#action_12373864 ] 
            
Ahti Kitsik commented on JBRULES-1127:
--------------------------------------

Comment from Mark:
getInputs gets all used external identifiers
then call isResolvable() which lazily creates the resolver
then you can do getVariableResolvers().get(identifier).getValue()

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 22:57:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 22:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1127) External vars
 do not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27111762.1188097038350.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=comments#action_12373870 ] 
            
Mark Proctor commented on JBRULES-1127:
---------------------------------------

I think I can fix this my end by updating the MVEL Factory, think I have a clean way of doing this - just debugging it now.

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 23:05:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Aug 2007 23:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1172)
 CacheLoaderInterceptor doesn't
 load data for Node.getKeys() or Node.getData()
Message-ID: <12017577.1188097518214.JavaMail.jira@cloud.prod.atl2.jboss.com>

CacheLoaderInterceptor doesn't load data for Node.getKeys() or Node.getData()
-----------------------------------------------------------------------------

                 Key: JBCACHE-1172
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1172
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 2.0.0.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: 2.1.0.GA


CacheLoaderInterceptor.mustLoad always returns false if there is no data key associated with the MethodCall.  Effect is calls for CacheImpl._getKeys  and _getData don't trigger a load from the cache loader.

Added tests testKeyKeys() and testGetData() to CacheLoaderTestsBase to show the issue.

Solution is to add a boolean 'allKeys' variable to CacheLoaderInterceptor.invoke.  Set it to true if the MethodCall is _getKeys or _getData.  Pass the value through to mustLoad, and if true load the data if Node.isDataLoaded returns 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 lists.jboss.org  Sat Aug 25 23:11:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 25 Aug 2007 23:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1127) External vars do
 not appear if you hve a break point on the first line
In-Reply-To: <19763242.1188008364937.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12654103.1188097878263.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1127?page=all ]

Mark Proctor closed JBRULES-1127.
---------------------------------

    Resolution: Done

yes managed to fix this in the factory, in debug mode it eager creates the external resolvers. The impl is quite clean, so I'm happy with it this way. Found another MVEL bug, where it doesn't find all external inputs, have creating a failing test in MVEL for this.

> External vars do not appear if you hve a break point on the first line
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1127
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1127
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: debugvars1.jpg, debugvars2.jpg
>
>
> if I add a break point to the second line all external vars are visible, but not on the first 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 lists.jboss.org  Sat Aug 25 23:19:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Aug 2007 23:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1172)
 CacheLoaderInterceptor doesn't
 load data for Node.getKeys() or Node.getData()
In-Reply-To: <12017577.1188097518214.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15336328.1188098358228.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1172?page=all ]

Brian Stansberry closed JBCACHE-1172.
-------------------------------------

    Resolution: Done

> CacheLoaderInterceptor doesn't load data for Node.getKeys() or Node.getData()
> -----------------------------------------------------------------------------
>
>                 Key: JBCACHE-1172
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1172
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 2.0.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.1.0.GA
>
>
> CacheLoaderInterceptor.mustLoad always returns false if there is no data key associated with the MethodCall.  Effect is calls for CacheImpl._getKeys  and _getData don't trigger a load from the cache loader.
> Added tests testKeyKeys() and testGetData() to CacheLoaderTestsBase to show the issue.
> Solution is to add a boolean 'allKeys' variable to CacheLoaderInterceptor.invoke.  Set it to true if the MethodCall is _getKeys or _getData.  Pass the value through to mustLoad, and if true load the data if Node.isDataLoaded returns 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 lists.jboss.org  Sun Aug 26 00:32:30 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 26 Aug 2007 00:32:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22218318.1188102750238.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1134?page=comments#action_12373873 ] 
            
Mark Proctor commented on JBRULES-1134:
---------------------------------------

This may be an MVEL issue, I'm debugging this one myself at the moment,to try and pin point where its going wrong.

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 01:34:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Sun, 26 Aug 2007 01:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1059)
 DistributedTopicTest::testClusteredTopicDurablePersistent fails
In-Reply-To: <16209021.1187999598708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4309432.1188106458239.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1059?page=all ]

Clebert Suconic closed JBMESSAGING-1059.
----------------------------------------

    Resolution: Done

> DistributedTopicTest::testClusteredTopicDurablePersistent fails
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1059
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1059
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>         Attachments: jbmessaging-1059.patch
>
>
> Due to message suckers still having message on subscribed topics (due to the second send loop), message suckers are causing failures on unbindQueue...
> There is a patch attached for a probable fix on the test.. but I want to investigate this before committing the 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 lists.jboss.org  Sun Aug 26 08:38:35 2007
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 26 Aug 2007 08:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1135) Move generation
 should be described in a drl
Message-ID: <10304513.1188131915761.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move generation should be described in a drl
--------------------------------------------

                 Key: JBRULES-1135
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1135
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Solver
    Affects Versions:  4.0.0.GA
            Reporter: Geoffrey De Smet
         Assigned To: Geoffrey De Smet
             Fix For: FUTURE


instead of MoveFactory POJO

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 08:55:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Aug 2007 08:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1114) Rule compilation
 not thread-safe
In-Reply-To: <28352887.1187868978351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13791079.1188132918341.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1114?page=all ]

Edson Tirelli resolved JBRULES-1114.
------------------------------------

    Resolution: Done

Problem was fixed in mvel template engine. Fix will be included in 4.0.1 release.

Thank you for reporting and providing such a good test case.




> Rule compilation not thread-safe
> --------------------------------
>
>                 Key: JBRULES-1114
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1114
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Dean Jones
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: PackageBuilderThreadSafetyTest.java
>
>
> Where multiple threads are compiling rules, the generated packages do not accurately reflect the rules being compiled.
> See http://thread.gmane.org/gmane.comp.java.drools.user/7834

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 09:29:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Aug 2007 09:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1110) Rules with 'From'
 condition with another not using From causes problem
In-Reply-To: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12986666.1188134958308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1110?page=all ]

Edson Tirelli updated JBRULES-1110:
-----------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

Arjun,

Can you please provide a self contained test case? I was not able to reproduce the problem with trunk (revision #14592) and our test classes.

Thanks
Edson

> Rules with 'From' condition with another not using From causes problem
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1110
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Decision tables
>    Affects Versions:  4.0.0.GA
>         Environment: Any
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> Test case:
> Write a Rule that uses a From clause and on another object does not use a from clause:
> example:
> #From row number: 28
> rule "Rules_28"
> 	
> 	when
> 		cntct: Contact(initialized==true)
> 		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
> 		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
> 	then
>                              System.out.println("Fired 28");
> end
> If All 3 are true:
>  1. Delete Condition 2 --> Rule fires
>  2. Delete COnditon 3 (But keep 2) --> Rule fires
>  3. Keep 2 & 3 (with 1) --> Rule does not fire
> Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.
> Please see if it is 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 lists.jboss.org  Sun Aug 26 10:37:27 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Aug 2007 10:37:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4632) Remove JBCACHE-1172
	workaround
Message-ID: <19809688.1188139047073.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove JBCACHE-1172 workaround
------------------------------

                 Key: JBAS-4632
                 URL: http://jira.jboss.com/jira/browse/JBAS-4632
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.0.0.GA


JBossCacheService.getAttrributes() has a small hacky workaround to JBCACHE-1172. Remove it once a JBC version with a fix is integrated in AS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:02:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
Message-ID: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule not firing when expression contains nested accessors
---------------------------------------------------------

                 Key: JBRULES-1136
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Wintel XP Pro SP2
            Reporter: sergey manukyan
         Assigned To: Mark Proctor


Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:

For example :

when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES

when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE

I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22532682.1188151458459.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: TestBug.java

JUnit Test Case

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1755096.1188151458613.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: TestSupplier.java

Test domain object

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27227339.1188151458770.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: TestBusinessStatus.java

Test domain object

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:04:18 2007
From: jira-events at lists.jboss.org (sergey manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17406440.1188151458943.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

sergey manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: RuleBaseFacade.java

Facade used to get RuleBase

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: sergey manukyan
>         Assigned To: Mark Proctor
>         Attachments: RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:06:22 2007
From: jira-events at lists.jboss.org (Sergey Manukyan (JIRA))
Date: Sun, 26 Aug 2007 14:06:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32355164.1188151582145.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

Sergey Manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: action_rules.drl

test rules

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Mark Proctor
>         Attachments: action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 14:54:28 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Aug 2007 14:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-849) DynamicRulesTest
 fails with JDK 1.6
In-Reply-To: <15921984.1178878322365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11604705.1188154468517.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-849?page=all ]

Edson Tirelli resolved JBRULES-849.
-----------------------------------

    Fix Version/s: 4.0.1
                       (was: FUTURE)
       Resolution: Done

Mark fixed this when did the changes on the PackageClassLoader. Fix included in 4.0.1.

> DynamicRulesTest fails with JDK 1.6
> -----------------------------------
>
>                 Key: JBRULES-849
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-849
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.0.MR2
>         Environment: Linux, JDK 1.6
>            Reporter: Lars Ivar Igesund
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> I'm doing mvn install from trunk, using JDK 1.6 on Kubuntu Linux.
> For module drools-compiler, testDynamicFunction in the file below results in an  ERROR 
>  drools-compiler/src/test/java/org/drools/integrationtests/DynamicRulesTest.java
> The contents of drools-compiler/target/surefire-reports/org.drools.integrationtests.DynamicRulesTest.txt are
> ------------------------------------------------------------------------------
> Test set: org.drools.integrationtests.DynamicRulesTest
> -------------------------------------------------------------------------------
> Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.008 sec <<< FAILURE!
> testDynamicFunction(org.drools.integrationtests.DynamicRulesTest)  Time elapsed: 0.036 sec  <<< ERROR!
> java.lang.NoClassDefFoundError: org/drools/test/AddFive
>     at org.drools.test.Rule_global_rule_test_0.consequence(Rule_global_rule_test_0.java:9)
>     at org.drools.test.Rule_global_rule_test_0ConsequenceInvoker.evaluate(Rule_global_rule_test_0ConsequenceInvoker.java:20)
>     at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:497)
>     at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:461)
>     at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:372)
>     at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:353)
>     at org.drools.integrationtests.DynamicRulesTest.testDynamicFunction(DynamicRulesTest.java:312)
>     at org.drools.integrationtests.DynamicRulesTest.testDynamicFunction(DynamicRulesTest.java:312)
>     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 sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
>     at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>     at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>     at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>     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 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
>     at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:17:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1129) import does not
 work with code competion
In-Reply-To: <10166143.1188058338307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9845360.1188163038293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1129?page=all ]

Kris Verlaenen resolved JBRULES-1129.
-------------------------------------

    Resolution: Done

Fixed by working around an eclipse jdt code completion bug.

> import does not work with code competion
> ----------------------------------------
>
>                 Key: JBRULES-1129
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1129
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>            Priority: Blocker
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> imports have regressed in the IDE. The drop down for context assist works fine, but I canot get it to write the actual text out - either by double clicking the entry or pressing enter. This is urgent, please fix asap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:19:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1057) properties
 keyword list is missing memberof
In-Reply-To: <11968073.1186139929349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2209186.1188163158273.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1057?page=all ]

Kris Verlaenen resolved JBRULES-1057.
-------------------------------------

    Resolution: Done

> properties keyword list is missing memberof
> -------------------------------------------
>
>                 Key: JBRULES-1057
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1057
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>
> Can you liaise with Edson, make sure all the correct properties are in syntax highlighting and auto completion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:21:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1108) Eclipse DRL
 editor unusable on dark background
In-Reply-To: <28516158.1187748618463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3260030.1188163278951.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1108?page=all ]

Kris Verlaenen reassigned JBRULES-1108:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)

> Eclipse DRL editor unusable on dark background
> ----------------------------------------------
>
>                 Key: JBRULES-1108
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1108
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.3.0
>            Reporter: Luke Maurer
>         Assigned To: Kris Verlaenen
>             Fix For: FUTURE
>
>
> Having a dark background color for editors in Eclipse makes the default DRL syntax highlighting unusable (as is the case with most Eclipse editors). Unfortunately, the editor's syntax highlighting can be neither changed nor disabled, so the DRL editor is completely unusable for me. While fully customizable syntax highlighting would be the best, simply being able to disable it entirely (and use Eclipse's default text color, which I of course have set to white) would be a perfectly good workaround.
> I set the background color to black in Preferences -> General -> Editors -> Text Editors -> Background color, and the foreground color to white on the same page.
> (Of course, this is really Eclipse's fault for forcing every single editor to have its very own ad-hoc syntax highlighting configuration system ... but I'd better not get started :-) )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:21:19 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:21:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1130) Code completion
 does not work for two char operator symbols
In-Reply-To: <22006280.1188059058281.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13122980.1188163279146.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1130?page=all ]

Kris Verlaenen updated JBRULES-1130:
------------------------------------

    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Code completion does not work for two char operator symbols
> -----------------------------------------------------------
>
>                 Key: JBRULES-1130
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1130
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: FUTURE
>
>         Attachments: screenshot-1.jpg
>
>
> When typing the first char of an operator, it does not show you the correct matches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:21:20 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:21:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1108) Eclipse DRL
 editor unusable on dark background
In-Reply-To: <28516158.1187748618463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22182233.1188163280421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1108?page=all ]

Kris Verlaenen updated JBRULES-1108:
------------------------------------

    Fix Version/s: FUTURE

> Eclipse DRL editor unusable on dark background
> ----------------------------------------------
>
>                 Key: JBRULES-1108
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1108
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>         Environment: Eclipse 3.3.0
>            Reporter: Luke Maurer
>         Assigned To: Kris Verlaenen
>             Fix For: FUTURE
>
>
> Having a dark background color for editors in Eclipse makes the default DRL syntax highlighting unusable (as is the case with most Eclipse editors). Unfortunately, the editor's syntax highlighting can be neither changed nor disabled, so the DRL editor is completely unusable for me. While fully customizable syntax highlighting would be the best, simply being able to disable it entirely (and use Eclipse's default text color, which I of course have set to white) would be a perfectly good workaround.
> I set the background color to black in Preferences -> General -> Editors -> Text Editors -> Background color, and the foreground color to white on the same page.
> (Of course, this is really Eclipse's fault for forcing every single editor to have its very own ad-hoc syntax highlighting configuration system ... but I'd better not get started :-) )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 17:29:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4352853.1188163758283.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=comments#action_12373913 ] 
            
Kris Verlaenen commented on JBRULES-1131:
-----------------------------------------

This is caused because the error thrown by the parser does not contain enough information.
The parser contains a fromDescr, which should have a lineNumber.
The IDE will then use this lineNumber and also create a marker.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sun Aug 26 17:31:18 2007
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Sun, 26 Aug 2007 17:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31097917.1188163878338.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=all ]

Kris Verlaenen reassigned JBRULES-1131:
---------------------------------------

    Assignee: Edson Tirelli  (was: Kris Verlaenen)

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Sun Aug 26 19:29:18 2007
From: jira-events at lists.jboss.org (Matthew Robinson (JIRA))
Date: Sun, 26 Aug 2007 19:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4633) ClientAbortException
 stacktrace lines log as separate Log4J events.
Message-ID: <3153777.1188170958334.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClientAbortException stacktrace lines log as separate Log4J events.
-------------------------------------------------------------------

                 Key: JBAS-4633
                 URL: http://jira.jboss.com/jira/browse/JBAS-4633
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-4.0.5.GA
         Environment: SuSE Linux 10.0
            Reporter: Matthew Robinson
         Assigned To: Remy Maucherat
            Priority: Minor


A ClientAbortException is raised legitimately when an end-user closes thier browser before the web app is finished responding to the request.

However, when the stacktrace is generated, it seems that each line is being logged using separate Log4J logger.log() call.  This results in a nice looking file-base log:

2007-08-27 09:10:31,402 ERROR [STDERR] ClientAbortException:  java.net.SocketException: Broken pipe
2007-08-27 09:10:31,640 ERROR [STDERR]  at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:366)
2007-08-27 09:10:31,937 ERROR [STDERR]  at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:353)
2007-08-27 09:10:32,131 ERROR [STDERR]  at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392)
2007-08-27 09:10:32,326 ERROR [STDERR]  at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
2007-08-27 09:10:32,607 ERROR [STDERR]  at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:88)
...

But it causes unnecessary grief and clutter when using SMTP to log errors.  Each line results in a separate email!  So my inbox fills with an average of 60 emails per ClientAbortException!

This problem seems to confined to the ClientAbortException.  Other errors log the stacktrace as a single Log4J event.  Please may I have this error logged in the same way?

Ta.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 20:00:29 2007
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Sun, 26 Aug 2007 20:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1173)
 o.j.c.u.ThreadGate does not implement timeouts properly
Message-ID: <17723921.1188172829784.JavaMail.jira@cloud.prod.atl2.jboss.com>

o.j.c.u.ThreadGate does not implement timeouts properly
-------------------------------------------------------

                 Key: JBCACHE-1173
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1173
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Jason T. Greene
         Assigned To: Jason T. Greene


This should be rewritten to use j.u.c Condition instead of object.wait()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Aug 26 20:57:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Sun, 26 Aug 2007 20:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1119)
 "ExpanderResolver was not
 set" when DSL and DRL in separate resource folders.
In-Reply-To: <20836012.1187898802270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16154025.1188176238677.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1119?page=comments#action_12373919 ] 
            
Michael Neale commented on JBRULES-1119:
----------------------------------------

Is the ant task for this something you have written? as the DSL file can be read in from anywhere (just not sure what can be done to do this - if you are loading rules from the API you can store things however you want). Or is this the drools-ant module?

> "ExpanderResolver was not set" when DSL and DRL in separate resource folders.
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1119
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1119
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions: 3.0.5
>         Environment: - Eclipse 3.2.1
> - WinXP
>            Reporter: Davy Toch
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>         Attachments: jbossrulesproject_one_resource_folder.zip, jbossrulesproject_two_resource_folders.zip
>
>
> 1. jbossrulesproject_one_resource_folder.zip
> - DRL and DSL in one resource folder
> - no problem
> 2. jbossrulesproject_two_resource_folders.zip
> - DRL and DSL in separate resource folders
> - causes error message : "ExpanderResolver was not set"
> We actually prefer two separate resource folders, because the rules are generated during the ANT
> build from the decision tables (so in target/...), while the DSL isn't automatically generated (so
> in 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 lists.jboss.org  Sun Aug 26 22:28:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 26 Aug 2007 22:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1137) Rules are not
 removed when they have shared nodes
Message-ID: <23465708.1188181698203.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rules are not removed when they have shared nodes
-------------------------------------------------

                 Key: JBRULES-1137
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1137
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 4.0.1


If any nodes are shared in a rule, then the rule is not correctly 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 lists.jboss.org  Sun Aug 26 22:31:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 26 Aug 2007 22:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1137) Rules are not
 removed when they have shared nodes
In-Reply-To: <23465708.1188181698203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27785869.1188181878222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1137?page=all ]

Mark Proctor closed JBRULES-1137.
---------------------------------

    Resolution: Done

> Rules are not removed when they have shared nodes
> -------------------------------------------------
>
>                 Key: JBRULES-1137
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1137
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>
> If any nodes are shared in a rule, then the rule is not correctly 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 lists.jboss.org  Mon Aug 27 02:02:18 2007
From: jira-events at lists.jboss.org (sreeni sabapathy (JIRA))
Date: Mon, 27 Aug 2007 02:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12942126.1188194538341.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373928 ] 
            
sreeni sabapathy commented on JBRULES-1121:
-------------------------------------------

Thank you for the quick response.

"=" would do the calculation, but calculation is based on values of other variables.

Here the rule itself does the calculation for the S.I, that is 

SI = P*T*R/100

writing the above in drools 3.0 it would be

then

m.setSimpleInterest(m.getPrinciple()*m.getTime()*m.getRate()/100);

While considering the drools-jbrms, I am not able to look up the values of other variables in "then" part, 

presently the calculation written in drools-jbrms is just 

SI =100*6*5/100;

but I wanted to have it as 

SI = P*T*R/100; 

The above can be achieved through the option "Bussiness rule through dsl(text editor)". As jbrms is defined for not technical user ( Bussiness user ) I would appreciate if above facility is avaliable in "Bussiness rule (using guided editor)".


> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 02:59:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 27 Aug 2007 02:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17973492.1188197958306.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373935 ] 
            
Michael Neale commented on JBRULES-1121:
----------------------------------------

If you use "=" - you can do similar to what you would do in DRL for that fields value: 
eg, try: 
m.principle * m.time * (m.rate /100)

This of course assumes you have "m" bound on the left hand side of a rule. 

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 03:29:22 2007
From: jira-events at lists.jboss.org (sreeni sabapathy (JIRA))
Date: Mon, 27 Aug 2007 03:29:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11822759.1188199762051.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12373937 ] 
            
sreeni sabapathy commented on JBRULES-1121:
-------------------------------------------

The calculation box does not take in any alphabets,but it takes in special characters and numerals, as the "SI" is of float data type.

If the variable is of string type it takes all the keys.

can you please suggest me in how to remove the data type validation in jbrms.

What my idea is, in the "when" part, we have an option of "bound with variable", similar to it can we have "computation on variables" in "then" part.The functionality will be same, just the difference in usage.

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 04:19:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 27 Aug 2007 04:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25132212.1188202758923.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=all ]

Carlo de Wolf updated EJBTHREE-1025:
------------------------------------

    Description: 
>From the API doc:
"When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."

Thus the following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

  was:
The following is an illegal construct:

@Stateless
@Local
@Remote
public class OrderServiceBean implements OrderService {...}

There is a test for this construct in Branch_4_2.


> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 04:45:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 04:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-583) Create JChannel based
 on XML file and stack name (similar to MuxChannel creation)
Message-ID: <4196328.1188204318219.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create JChannel based on XML file and stack name (similar to MuxChannel creation)
---------------------------------------------------------------------------------

                 Key: JGRP-583
                 URL: http://jira.jboss.com/jira/browse/JGRP-583
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.7


Example: Channel ch=new JChannel("stacks.xml", "udp"). This creates a UDP based protocol stack, based on stacks.xml. The advantage is to maintain all protocol stack configurations in the same 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 lists.jboss.org  Mon Aug 27 04:56:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 04:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-409) Channel bundling
In-Reply-To: <24082841.1168897432592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2705414.1188204978228.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-409?page=comments#action_12373938 ] 
            
Bela Ban commented on JGRP-409:
-------------------------------

Correction: no, it won't. Without logical addresses, channel bundling will only work with UDP. Use IP Bonding or something similar to do the same for TCP

> Channel bundling
> ----------------
>
>                 Key: JGRP-409
>                 URL: http://jira.jboss.com/jira/browse/JGRP-409
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> We can distributed traffic across multiple sockets in the transport. E.g. if we have eth0 and eth1, and both are 100Mbps *full duplex*, then we should be able to send 100Mbps on eth0 and 100Mbps on eth1 *simultaneously*.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 06:30:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 06:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1641) Portal link
 (top right of page) in admin results in 403 error
In-Reply-To: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22212131.1188210618431.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1641?page=comments#action_12373948 ] 
            
Thomas Heute commented on JBPORTAL-1641:
----------------------------------------

It shouldn't with a fresh database. Can you confirm ?

> Portal link (top right of page) in admin results in 403 error
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1641
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.8 Final
>            Reporter: Chris Laprun
>             Fix For: 2.8 Final
>
>
> Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 06:32:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 06:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10429650.1188210738315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1648?page=all ]

Thomas Heute updated JBPORTAL-1648:
-----------------------------------

    Fix Version/s: 2.6.2 Final
         Assignee: Thomas Heute

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 06:34:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 06:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4634) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.0.SP4)
Message-ID: <21208408.1188210858201.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss remoting to v2.2.2.GA (from v2.2.0.SP4)
-----------------------------------------------------

                 Key: JBAS-4634
                 URL: http://jira.jboss.com/jira/browse/JBAS-4634
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Dimitris Andreadis
             Fix For:  JBossAS-5.0.0.Beta3


Upgrade to latest remoting 2.2.2.GA when it becomes available.

Upgraded to jboss remoting 2.2.1.GA in the meantime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 07:18:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 07:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31834321.1188213498226.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12373954 ] 
            
Dimitris Andreadis commented on JBAS-4562:
------------------------------------------

Library tidy up #1

a) Synch with AS 4.2.x
xdoclet to 1.2.3-brew (from 1.2b3) 
remoting to 2.2.1 for now and eventually to 2.2.2 when available (now at 2.2.0.SP4) 

b) Remove duplicate dom4j entry 1.6.1jboss, leave 1.6.1-brew

    <componentref name="dom4j" version="1.6.1-brew"/>
    <componentref name="dom4j" version="1.6.1jboss"/> 

c) Remove

- unused wutka-dtdparser
  (build/runtime time dependency of jbossxb needed for DTD-based marshalling which is not used in the AS.)
- backport-concurrent
- jbossretro 


> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:29:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Mon, 27 Aug 2007 08:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1110) Rules with
 'From' condition with another not using From causes problem
In-Reply-To: <17014203.1187803818261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29471236.1188217758327.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1110?page=comments#action_12373958 ] 
            
Arjun Dhar commented on JBRULES-1110:
-------------------------------------

ok, will do so this weekend. Kindly do not close the bug till then. I'l lalso do some testing and verification at my end. The from works over a JDBC Connections. The actual code is really big with the base classes etc; so will try and dev a scaled down test case to help you.

In the process I may discover things myself. Kindly wait till this weekend, next monday before you decide to close this bug.

Thanks

> Rules with 'From' condition with another not using From causes problem
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1110
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1110
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Reteoo
>    Affects Versions:  4.0.0.GA
>         Environment: Any
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>             Fix For: FUTURE
>
>
> Test case:
> Write a Rule that uses a From clause and on another object does not use a from clause:
> example:
> #From row number: 28
> rule "Rules_28"
> 	
> 	when
> 		cntct: Contact(initialized==true)
> 		config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1")
> 		pref: Relation(contact==cntct, type=="old") or (eval(false==true)  and not Relation(contact==cntct, type=="old"))
> 	then
>                              System.out.println("Fired 28");
> end
> If All 3 are true:
>  1. Delete Condition 2 --> Rule fires
>  2. Delete COnditon 3 (But keep 2) --> Rule fires
>  3. Keep 2 & 3 (with 1) --> Rule does not fire
> Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work.
> Please see if it is 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 lists.jboss.org  Mon Aug 27 08:33:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1138) MVEL code
 completion does not work for objects as params
Message-ID: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>

MVEL code completion does not work for objects as params
--------------------------------------------------------

                 Key: JBRULES-1138
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:33:18 2007
From: jira-events at lists.jboss.org (Arjun Dhar (JIRA))
Date: Mon, 27 Aug 2007 08:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1111) Final methods
 of POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22161720.1188217998538.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=comments#action_12373960 ] 
            
Arjun Dhar commented on JBRULES-1111:
-------------------------------------

Hi,
  true; but this needs to be documented. From an end user perrspective it is still unexpected behaviour. So kindly add it to your documentation. The version I have does not reflect this fact. For this i dont think its necessary to reopen or issue a new bug, but would be thoughtful if it can be or is already proved in the formal released docs.

Thanks

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:35:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for objects as params
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17040182.1188218118282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1138?page=all ]

Mark Proctor updated JBRULES-1138:
----------------------------------

    Attachment: screenshot-1.jpg

code completion not working

> MVEL code completion does not work for objects as params
> --------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:37:22 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:37:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for objects as params
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23874923.1188218242176.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1138?page=all ]

Mark Proctor updated JBRULES-1138:
----------------------------------

    Attachment: screenshot-2.jpg

code completion working

> MVEL code completion does not work for objects as params
> --------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:37:22 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 08:37:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-203) Primary Partiton
 approach for handling of partitions
Message-ID: <28454553.1188218242309.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-203?page=comments#action_12373963 ] 
            
Bela Ban commented on JGRP-203:
-------------------------------

I added documentation to the manual at http://www.jgroups.org/javagroupsnew/docs/manual/html/index.html ("handling network partitions").

> Primary Partiton approach for handling of partitions
> ----------------------------------------------------
>
>                 Key: JGRP-203
>                 URL: http://jira.jboss.com/jira/browse/JGRP-203
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: PRIMARY_PARTITION.java
>
>
> Add this approach to JGroups. Members in a non-primary partition will shut down, become read-only etc.
> Google for "primary partition AND group communication" for the relevant literature on 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 lists.jboss.org  Mon Aug 27 08:39:29 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Aug 2007 08:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-203) Primary Partiton
 approach for handling of partitions
Message-ID: <33039147.1188218369547.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-203?page=all ]

Bela Ban resolved JGRP-203.
---------------------------

    Resolution: Done

This functionality doesn't require an additional protocol, and can be handled entirely by writing code in the viewAccepted() callback. There is an example PrimaryPartitionTest which demos this.

> Primary Partiton approach for handling of partitions
> ----------------------------------------------------
>
>                 Key: JGRP-203
>                 URL: http://jira.jboss.com/jira/browse/JGRP-203
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>         Attachments: PRIMARY_PARTITION.java
>
>
> Add this approach to JGroups. Members in a non-primary partition will shut down, become read-only etc.
> Google for "primary partition AND group communication" for the relevant literature on 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 lists.jboss.org  Mon Aug 27 08:48:26 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:48:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1139) code completion
 doesn't work as you type
Message-ID: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>

code completion doesn't work as you type
----------------------------------------

                 Key: JBRULES-1139
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:50:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:50:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27020572.1188219050116.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1139?page=all ]

Mark Proctor updated JBRULES-1139:
----------------------------------

    Attachment: screenshot-1.jpg

Correctly shows the field names

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 08:50:50 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 08:50:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23601026.1188219050547.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1139?page=all ]

Mark Proctor updated JBRULES-1139:
----------------------------------

    Attachment: screenshot-2.jpg

This is after I press 'n' see it does not show the fields, ony matching methods.

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:07:18 2007
From: jira-events at lists.jboss.org (Sergey Manukyan (JIRA))
Date: Mon, 27 Aug 2007 09:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5241341.1188220038691.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

Sergey Manukyan updated JBRULES-1136:
-------------------------------------

    Description: 
Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:

For example :

when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES

when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE

I am using StatefulSession.  Will attach the unit test to reproduce the problem.

Just found same issue happens in other construct like collect :

when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES


  was:
Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:

For example :

when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES

when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE

I am using StatefulSession.  Will attach the unit test to reproduce the problem.


> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Mark Proctor
>         Attachments: action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:11:18 2007
From: jira-events at lists.jboss.org (Sergey Manukyan (JIRA))
Date: Mon, 27 Aug 2007 09:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24430661.1188220278324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

Sergey Manukyan updated JBRULES-1136:
-------------------------------------

    Attachment: action_rules.drl

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Mark Proctor
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:30:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 27 Aug 2007 09:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26054406.1188221419005.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12373980 ] 
            
Carlo de Wolf commented on EJBTHREE-1025:
-----------------------------------------

Make sure the error references this issue.

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:34:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1111) Final methods
 of POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4106483.1188221658374.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=comments#action_12373981 ] 
            
Edson Tirelli commented on JBRULES-1111:
----------------------------------------

Arjun, 

Yes, agreed. Will do it.


> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:34:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31104053.1188221658525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=all ]

Edson Tirelli reopened JBRULES-1111:
------------------------------------

             
Reopening ticket to update documentation.

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: 4.0.1
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:36:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1111) Final methods of
 POJO's aer never evaluated
In-Reply-To: <19347169.1187803938267.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21726086.1188221778336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1111?page=all ]

Edson Tirelli updated JBRULES-1111:
-----------------------------------

      Component/s: Documentation
    Fix Version/s: FUTURE
                       (was: 4.0.1)

> Final methods of POJO's aer never evaluated
> -------------------------------------------
>
>                 Key: JBRULES-1111
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1111
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo, Documentation
>    Affects Versions:  4.0.0.GA
>            Reporter: Arjun Dhar
>         Assigned To: Edson Tirelli
>            Priority: Minor
>             Fix For: FUTURE
>
>
> If a POJO defines certain getters as final and they are used in a condition in the Rules, then they do not evaluate properly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:36:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 27 Aug 2007 09:36:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13867689.1188221778579.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

Edson Tirelli reassigned JBRULES-1136:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Edson Tirelli
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 09:53:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 09:53:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1623) Create "Admin"
 icon for the different themes for the new admin portlet mode
In-Reply-To: <19138744.1186510029362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12320562.1188222799348.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1623?page=all ]

Thomas Heute resolved JBPORTAL-1623.
------------------------------------

    Fix Version/s:     (was: 2.6.3 Final)
       Resolution: Partially Completed
         Assignee: Thomas Heute  (was: Julien Viet)

Not great but done.

> Create "Admin" icon for the different themes for the new admin portlet mode
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1623
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1623
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 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 lists.jboss.org  Mon Aug 27 09:53:19 2007
From: jira-events at lists.jboss.org (Huishan Zhou (JIRA))
Date: Mon, 27 Aug 2007 09:53:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1112) drools-jbrms.war
 does not work with JBoss4.0.5 bundled with Jetty6.1.1
Message-ID: <30881312.1188222799547.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1112?page=all ]

Huishan Zhou updated JBRULES-1112:
----------------------------------

    Complexity: Medium

This morning, I tested drools-jbrms.war (without any change to this war) downloaded from 
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules/drools-4.0.1.SNAPSHOT-brms.zip 
 and tested on standalone Jetty-6.1.1 with three jar files, jboss-faces.jar, jsf-impl.jar and jsf-api.jar, added in the lib directory of Jetty server, downloaded from the site 
http://www.icefaces.org/JForum/posts/downloadAttach/1321.page 

I got the following error:
Failed startup of context org.mortbay.jetty.webapp.WebAppContext at ....drools-jbrms,...
org.drools.repository.RulesRepositoryException: javax.jcr.RepositoryException
...

Would you mind to send me your three jar files for me to test?
Regards,



> drools-jbrms.war does not work with JBoss4.0.5 bundled with Jetty6.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBRULES-1112
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1112
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP Professional 2002 service pack 2, JDK1.6.0
>            Reporter: Huishan Zhou
>         Assigned To: Fernando Meyer
>            Priority: Critical
>             Fix For: FUTURE
>
>
> The bugs of the following test is based on running drools-jbrms.war
> on JBoss4.0.5 bundled with Jetty6.1.1.  (No bugs on running this war in
> JBoss4.0.5 bundled with Tomcat5.5)
> drools-jbrms.war is extracted from drools-4.0.0-brms.zip
> which is downloaded from 
> http://labs.jboss.com/drools/downloads.html on 08/21/2007.
> (I also tested drools-jbrms.war extracted from 
> jbossrules-4.0.0.12865MR3-brms.zip
> downloaded from 
> http://labs.jboss.com/jbossrules/downloads
> on 08/20/2007. Identical error message.)
> (1)     during starting of JBoss, it throws the 
> ClassNotFoundException, javax/faces/context/FacesContext,
> and in web browser console, it showed that drools-jbrms deployment
> failed.
> We have fixed this exception by adding two jar files, jsf-impl.jar 
> and jsf-api.jar, to WEB-INF/lib
> (2)     After fixing errors in (1) we can start JBoss.  And we can go 
> to 
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> welcome.jsp 
> and      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.html with the showup of the code of JBRMS.html itself, not
> the user name and password form that was showed up in the JBoss4.0.5 
> bundled with Tomcat5.5
> and
> we can also go to      
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> login.jsp (What is the purpose of this page?)
> If we try to go to   
> http://localhost:8080/drools-jbrms/drools-jbrms/org.drools.brms.JBRMS/
> JBRMS.jsp 
> we got error.  We opened JBRMS.jsp, we found that it missed one very 
> basic line (but this missing didn't cause any trouble while testing in 
> JBoss bundled with Tomcat ?)
> <%@ page language="java" import="org.jboss.seam.security.Identity" 
> pageEncoding="ISO-8859-1"%>
> After adding this line to the code.  We still got errors:
> = = = = errors message = = = =
> org.apache.jasper.JasperException: Unable to compile class for JSP
> Generated servlet error:
> Only a type can be imported. org.jboss.seam.security.Identity 
> resolves to a package
> An error occurred at line: 11 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> Identity cannot be resolved to a type
> An error occurred at line: 10 in the jsp file: 
> /drools-jbrms/org.drools.brms.JBRMS/JBRMS.jsp
> Generated servlet error:
> org.jboss.seam.security.Identity cannot be resolved to a type
> = = = = = = = = = = = = = = = = = = =
> We have checked that the jar file for the class 
> org.jboss.seam.security.Identity is in the WEB-INF/lib of 
> drools-jbrms.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 lists.jboss.org  Mon Aug 27 11:00:27 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Mon, 27 Aug 2007 11:00:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1641) Portal link
 (top right of page) in admin results in 403 error
In-Reply-To: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21760249.1188226827223.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1641?page=comments#action_12374000 ] 
            
Chris Laprun commented on JBPORTAL-1641:
----------------------------------------

Indeed, the issue doesn't exist with a clean DB.

> Portal link (top right of page) in admin results in 403 error
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1641
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.8 Final
>            Reporter: Chris Laprun
>             Fix For: 2.8 Final
>
>
> Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:06:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 11:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1641) Portal link
 (top right of page) in admin results in 403 error
In-Reply-To: <5602416.1187716458802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16251750.1188227178419.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1641?page=all ]

Thomas Heute resolved JBPORTAL-1641.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute

So i close it :)

In 2.6.2 it is fixed in a different way (slightly less clean) that doesn't require to wipe out the DB.


> Portal link (top right of page) in admin results in 403 error
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-1641
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1641
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.8 Final
>            Reporter: Chris Laprun
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final
>
>
> Log in as admin/admin, click on Portal link at the top right of the page => 403

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:18:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Mon, 27 Aug 2007 11:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1614) Cannot access
 dashboard if logged in as user that has a "." (dot) in the username
In-Reply-To: <22699464.1185480602670.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31143582.1188227898344.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1614?page=all ]

Thomas Heute resolved JBPORTAL-1614.
------------------------------------

    Resolution: Done

Fixed

> Cannot access dashboard if logged in as user that has a "." (dot) in the username
> ---------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1614
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1614
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP, Firefox/IE
>            Reporter: krish p
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> Go to this link, http://portal.demo.jboss.com/portal/default, and try adding a user with a "." in the username. And login as that user. Click on dashboard. It will fail. This issue does not reproduce if the username doesn't have any dots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:28:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4635) Fix
	jboss-head-testsuite-sun-1.5
Message-ID: <20812922.1188228498190.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix jboss-head-testsuite-sun-1.5
--------------------------------

                 Key: JBAS-4635
                 URL: http://jira.jboss.com/jira/browse/JBAS-4635
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Dimitris Andreadis
             Fix For:  JBossAS-5.0.0.Beta3


Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5

Create subtasks for groups of 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 lists.jboss.org  Mon Aug 27 11:32:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4635) Fix
	jboss-head-testsuite-sun-1.5
In-Reply-To: <20812922.1188228498190.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3618408.1188228738291.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4635?page=all ]

Dimitris Andreadis updated JBAS-4635:
-------------------------------------

    Description: 
Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5

Create subtasks for groups of failing tests.

Initial count:

3369 122 226 89.67%

  was:
Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5

Create subtasks for groups of failing tests.


> Fix jboss-head-testsuite-sun-1.5
> --------------------------------
>
>                 Key: JBAS-4635
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4635
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Dimitris Andreadis
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Fix http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-sun-1.5
> Create subtasks for groups of failing tests.
> Initial count:
> 3369 122 226 89.67%

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:45:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4636) Fix
 org.jboss.test.deployers.* failures
Message-ID: <7103086.1188229518425.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.deployers.* failures
---------------------------------------

                 Key: JBAS-4636
                 URL: http://jira.jboss.com/jira/browse/JBAS-4636
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Dimitris Andreadis
             Fix For:  JBossAS-5.0.0.Beta3


Looking at the testsuite runs:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html

There is a whole group of deployer tests that need to be further qualified/fixed, with linked issues created

org.jboss.test.deployers.client.test 4 4 0 6.208 
org.jboss.test.deployers.ear.test 5 5 0 10.343 
org.jboss.test.deployers.ejb.test 4 4 0 9.456 
org.jboss.test.deployers.jbas2904.test 1 1 0 1.659 
org.jboss.test.deployers.rar.test 4 4 0 6.285 
org.jboss.test.deployers.sar.test 4 4 0 16.937 
org.jboss.test.deployers.web.test 4 4 0 30.319 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:49:18 2007
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 27 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4636) Fix
 org.jboss.test.deployers.* failures
In-Reply-To: <7103086.1188229518425.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27992496.1188229758507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4636?page=all ]

Ales Justin reassigned JBAS-4636:
---------------------------------

    Assignee: Ales Justin

> Fix org.jboss.test.deployers.* failures
> ---------------------------------------
>
>                 Key: JBAS-4636
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4636
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Ales Justin
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Looking at the testsuite runs:
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html
> There is a whole group of deployer tests that need to be further qualified/fixed, with linked issues created
> org.jboss.test.deployers.client.test 4 4 0 6.208 
> org.jboss.test.deployers.ear.test 5 5 0 10.343 
> org.jboss.test.deployers.ejb.test 4 4 0 9.456 
> org.jboss.test.deployers.jbas2904.test 1 1 0 1.659 
> org.jboss.test.deployers.rar.test 4 4 0 6.285 
> org.jboss.test.deployers.sar.test 4 4 0 16.937 
> org.jboss.test.deployers.web.test 4 4 0 30.319 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:55:32 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:55:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4637) Fix
 org.jboss.test.messaging.* tests
Message-ID: <30496584.1188230132824.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.messaging.* tests
------------------------------------

                 Key: JBAS-4637
                 URL: http://jira.jboss.com/jira/browse/JBAS-4637
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
             Fix For:  JBossAS-5.0.0.Beta3


http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html

The failing messaging tests need to be looked-up and further qualified or fixed. The failures are not necessarily messaging related:

SecurityUnitTestCase 30 0 9 21.235 
SecurityUnitTestCase(tests-jbossmessaging) 30 0 10 33.938 
SessionCloseStressTestCase(tests-standard-stress) 1 1 0 0.000 

UnackedUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 11:55:32 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 11:55:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4637) Fix
 org.jboss.test.messaging.* tests
In-Reply-To: <30496584.1188230132824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15425472.1188230132997.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4637?page=all ]

Dimitris Andreadis reassigned JBAS-4637:
----------------------------------------

    Assignee: Clebert Suconic

Clebert, can you help?

> Fix org.jboss.test.messaging.* tests
> ------------------------------------
>
>                 Key: JBAS-4637
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4637
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html
> The failing messaging tests need to be looked-up and further qualified or fixed. The failures are not necessarily messaging related:
> SecurityUnitTestCase 30 0 9 21.235 
> SecurityUnitTestCase(tests-jbossmessaging) 30 0 10 33.938 
> SessionCloseStressTestCase(tests-standard-stress) 1 1 0 0.000 
> UnackedUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 12:04:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 27 Aug 2007 12:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4637) Fix
 org.jboss.test.messaging.* tests
In-Reply-To: <30496584.1188230132824.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5129199.1188230658314.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4637?page=comments#action_12374015 ] 
            
Clebert Suconic commented on JBAS-4637:
---------------------------------------

SecurityUnitTestCase looks like something wrong on security... The same test pass on 4.2 without any changes... I will verify

> Fix org.jboss.test.messaging.* tests
> ------------------------------------
>
>                 Key: JBAS-4637
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4637
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Clebert Suconic
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/20070825220010/results/index.html
> The failing messaging tests need to be looked-up and further qualified or fixed. The failures are not necessarily messaging related:
> SecurityUnitTestCase 30 0 9 21.235 
> SecurityUnitTestCase(tests-jbossmessaging) 30 0 10 33.938 
> SessionCloseStressTestCase(tests-standard-stress) 1 1 0 0.000 
> UnackedUnitTestCase

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 12:39:23 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Aug 2007 12:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1174) Add further
	passivation docs
Message-ID: <8204338.1188232763535.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add further passivation docs
----------------------------

                 Key: JBCACHE-1174
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1174
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Cache loaders
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: 2.1.0.GA


Add discussion a la http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077805#4077805. I've already done this in my local checkout but can't figure out how to get the maven jdocbook stuff to run so I can validate.  This task is just a reminder to finish up once a more urgent need drives me to figure this stuff 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 lists.jboss.org  Mon Aug 27 12:47:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Mon, 27 Aug 2007 12:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4638) fix
 org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web
 2.0.1.CR6.
Message-ID: <14167343.1188233238869.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web 2.0.1.CR6.
-----------------------------------------------------------------------------------------

                 Key: JBAS-4638
                 URL: http://jira.jboss.com/jira/browse/JBAS-4638
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Dimitris Andreadis
         Assigned To: Remy Maucherat
             Fix For: JBossAS-4.2.2.GA


see http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-sun-1.5?log=log20070821220014

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 13:01:32 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Aug 2007 13:01:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4639) Optimized
 replication of ClusteredSession metadata
Message-ID: <10945788.1188234092145.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimized replication of ClusteredSession metadata
--------------------------------------------------

                 Key: JBAS-4639
                 URL: http://jira.jboss.com/jira/browse/JBAS-4639
             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


Stop storing clustered session metadata as a single key value pair in JBossCache.  Instead, separate those attributes prone to frequent change (s/b just the access timestamp) from those that are largely fixed at session creation.  Call cache.put() with the "fixed" ones only on the first request (or in the less likely event that something changes in them, e.g. timeout interval, in a later request.)  Store the timestamp with every request; perhaps less often if the request didn't change anything else in the session, i.e. no more often than every 30 secs.

With this we can get rid of hacky stuff like using Subject/Observer to track FIELD granularity pojo attribute changes.  We just do that so we know whether to replicate session the metadata.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 14:25:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 14:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1138) MVEL code
 completion does not work for objects as params
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16734537.1188239118419.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1138?page=comments#action_12374048 ] 
            
Philippe Ombredanne commented on JBRULES-1138:
----------------------------------------------

Ok, this has nothing to do with params, but with the fact we are asking completion for an nested expression, which is not yet syntactically correct mvel wise.
textArea.append ( $p 
will not compile in mvel, so we need to think about a way to transform that back into a balanced expression that could compile.
In that case the outer expression is irrelevant from a completion point of view. 
We would need to have some code to parse that, such that we can extract the inner expression and use it for completion.

> MVEL code completion does not work for objects as params
> --------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 16:05:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 16:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10068229.1188245118332.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1139?page=all ]

Philippe Ombredanne resolved JBRULES-1139.
------------------------------------------

    Resolution: Done

Fixed @ rev14666

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 16:05:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 16:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12075226.1188245118507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1139?page=all ]

Philippe Ombredanne reassigned JBRULES-1139:
--------------------------------------------

    Assignee: Mark Proctor  (was: Philippe Ombredanne)

For your review

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 16:07:19 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 16:07:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for nested expressions
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12903239.1188245239028.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1138?page=all ]

Philippe Ombredanne updated JBRULES-1138:
-----------------------------------------

    Summary: MVEL code completion does not work for nested expressions  (was: MVEL code completion does not work for objects as params)

> MVEL code completion does not work for nested expressions
> ---------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 17:17:18 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 17:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30375755.1188249438407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1134?page=all ]

Philippe Ombredanne updated JBRULES-1134:
-----------------------------------------

    Description: 
The drools variable appears twice in context compliation, once typed and once as Object.
Actually I could not reproduce that one. 
But in general variables may appear twice.

  was:The drools variable appears twice in context compliation, once typed and once as Object.


> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.
> Actually I could not reproduce that one. 
> But in general variables may appear twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 17:19:30 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 17:19:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24659357.1188249570206.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1134?page=all ]

Philippe Ombredanne resolved JBRULES-1134.
------------------------------------------

    Resolution: Done

Fixe @ rev 14669

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.
> Actually I could not reproduce that one. 
> But in general variables may appear twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 17:19:30 2007
From: jira-events at lists.jboss.org (Philippe Ombredanne (JIRA))
Date: Mon, 27 Aug 2007 17:19:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1134) drools variable
 appears twice in context assist
In-Reply-To: <4279454.1188090258307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29555110.1188249570420.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1134?page=all ]

Philippe Ombredanne reassigned JBRULES-1134:
--------------------------------------------

    Assignee: Mark Proctor  (was: Philippe Ombredanne)

For your review

> drools variable appears twice in context assist
> -----------------------------------------------
>
>                 Key: JBRULES-1134
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1134
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> The drools variable appears twice in context compliation, once typed and once as Object.
> Actually I could not reproduce that one. 
> But in general variables may appear twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 18:42:24 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 27 Aug 2007 18:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4638) fix
 org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web
 2.0.1.CR6.
In-Reply-To: <14167343.1188233238869.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11192069.1188254544452.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4638?page=comments#action_12374090 ] 
            
Remy Maucherat commented on JBAS-4638:
--------------------------------------

Ok. There are no changes at all in the SSL code, so it's strange. Maybe it relates to the logging update, but it's still completely unexpected.

> fix org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web 2.0.1.CR6.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-4638
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4638
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-4.2.2.GA
>
>
> see http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-sun-1.5?log=log20070821220014

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 20:50:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Mon, 27 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1121) Operator field
 and the
 fact's variable field required in the "then" part of the rule
In-Reply-To: <26598244.1187937569373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2451708.1188262218406.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1121?page=comments#action_12374097 ] 
            
Michael Neale commented on JBRULES-1121:
----------------------------------------

I have not been able to reproduce it. If you type "=" as the first character in the text box (talking about "then" of course) then it WILL let you put in numbers (or should). If not, then it is a bug (and we should log it as such). Can you provide more details on this?

Yes I like your idea of the "literal/formula" thing similar to the "when" part (but we want to keep it simple - as most of the time it is literal values or calculations).

> Operator field and the fact's variable field required in the "then" part of the rule
> ------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1121
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1121
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, drools-brms
>    Affects Versions:  4.0.0.GA
>         Environment: drools-jbrms stand alone and Eclipse drools-4.0.0 
>            Reporter: sreeni sabapathy
>         Assigned To: Michael Neale
>            Priority: Minor
>             Fix For: FUTURE
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> In the drools-jbrms standalone and even in the eclipse plugin version of "New guided drl file"
> the "then" part of the rule has the limitation of assigning the fixed value to the fact's variable.
> But in many condition the the value of the variable depends upon the value of another variable.
> I have taken  a simple example for explanation.
> For calcluating simple interest
> SI = P*T*R/100
> Now in the rule file if the 
> "when" condition as the check of " Calcluation type (simple ineterst or compound interest)"
> "then" part having SI, 
> At the present drool-jbrms definition the 
> "then" part has SI = text field.
> But my requirement is to look up the class variable "principle", "Time" and the "Rate" and then calculate, not just 
> assign some fixed values.
> In a simple sentence I would appreciate if the drools- jbrms has the options related to  "when" in the "then" part of the rule also.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 22:59:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 22:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1139) code completion
 doesn't work as you type
In-Reply-To: <11774409.1188218906598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24672575.1188269958217.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1139?page=all ]

Mark Proctor updated JBRULES-1139:
----------------------------------

    Attachment: screenshot-3.jpg

completion as you type works after the first . operator, but doesn't work on the first root itentifier. notice that "dr" is not showing drools, yet I saw it there if I did ctrl+space before typing "dr".

> code completion doesn't work as you type
> ----------------------------------------
>
>                 Key: JBRULES-1139
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1139
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg
>
>
> doing object. then ctrl+space shows the properties, if I type in a letter, it only shows the methods not the fields.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Aug 27 23:01:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 23:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1140) Context Assist
 does not show available declarations and globals
Message-ID: <7063853.1188270078538.JavaMail.jira@cloud.prod.atl2.jboss.com>

Context Assist does not show available declarations and globals
---------------------------------------------------------------

                 Key: JBRULES-1140
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1140
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Philippe Ombredanne
             Fix For: 4.0.1


when you do context assist at the start of a new statement all globals and declarations are of course available and show show in the context assist list, but 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 lists.jboss.org  Mon Aug 27 23:01:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 23:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1140) Context Assist
 does not show available declarations and globals
In-Reply-To: <7063853.1188270078538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19550725.1188270078716.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1140?page=all ]

Mark Proctor closed JBRULES-1140.
---------------------------------

    Resolution: Cannot Reproduce Bug

sorry ignore that one, was talking rubbish.

> Context Assist does not show available declarations and globals
> ---------------------------------------------------------------
>
>                 Key: JBRULES-1140
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1140
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.1
>
>
> when you do context assist at the start of a new statement all globals and declarations are of course available and show show in the context assist list, but 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 lists.jboss.org  Mon Aug 27 23:07:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 27 Aug 2007 23:07:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1141) context assist no
 longer works for functions in the drl.
Message-ID: <17049984.1188270438381.JavaMail.jira@cloud.prod.atl2.jboss.com>

context assist no longer works for functions in the drl.
--------------------------------------------------------

                 Key: JBRULES-1141
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1141
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 4.0.1


context assist no longer works for functions in the drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 04:57:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 04:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4640) JmsActivation
 reconnection could start multiple threads
Message-ID: <3182596.1188291438241.JavaMail.jira@cloud.prod.atl2.jboss.com>

JmsActivation reconnection could start multiple threads
-------------------------------------------------------

                 Key: JBAS-4640
                 URL: http://jira.jboss.com/jira/browse/JBAS-4640
             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.Beta3, JBossAS-4.2.2.GA


The jms inflow resource adapter could start multiple recovery threads if the exception listener is fired
during a reconnect after the connection is established.

There needs to be a guard to make sure only one thread is doing the 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 lists.jboss.org  Tue Aug 28 04:59:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 04:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4640) JmsActivation
 reconnection could start multiple threads
In-Reply-To: <3182596.1188291438241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5963459.1188291558332.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4640?page=all ]

Adrian Brock closed JBAS-4640.
------------------------------

    Resolution: Done

> JmsActivation reconnection could start multiple threads
> -------------------------------------------------------
>
>                 Key: JBAS-4640
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4640
>             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.Beta3, JBossAS-4.2.2.GA
>
>
> The jms inflow resource adapter could start multiple recovery threads if the exception listener is fired
> during a reconnect after the connection is established.
> There needs to be a guard to make sure only one thread is doing the 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 lists.jboss.org  Tue Aug 28 06:17:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 06:17:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4516) The transaction
 project needs moving out jboss-head since it is obsolete
In-Reply-To: <27290032.1183572051138.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15804145.1188296238517.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4516?page=all ]

Dimitris Andreadis updated JBAS-4516:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078676#4078676

Link to a forum discussion.

> The transaction project needs moving out jboss-head since it is obsolete
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4516
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4516
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.GA
>
>
> The transaction project in jboss-head is obsolete now that it uses JBossTM.
> The subtasks of this task describe what needs doing to complete 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 lists.jboss.org  Tue Aug 28 06:39:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
Message-ID: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>

Generify the lazy list, map and set implementations
---------------------------------------------------

                 Key: JBCOMMON-30
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: core
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For: 2.0.5.GA


Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 06:45:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:45:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
In-Reply-To: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24783881.1188297947943.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-30?page=all ]

Adrian Brock closed JBCOMMON-30.
--------------------------------

    Resolution: Done

> Generify the lazy list, map and set implementations
> ---------------------------------------------------
>
>                 Key: JBCOMMON-30
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.0.5.GA
>
>
> Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 06:45:48 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:45:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
Message-ID: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port generic collections from Microcontainer to common
------------------------------------------------------

                 Key: JBCOMMON-31
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For: 2.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 lists.jboss.org  Tue Aug 28 06:49:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:49:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1648) Undeploying a
 portlet in an exploded form causes a NullPointerException
In-Reply-To: <26071863.1187873374326.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31854539.1188298159606.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1648?page=all ]

Thomas Heute resolved JBPORTAL-1648.
------------------------------------

    Resolution: Done

> Undeploying a portlet in an exploded form causes a NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1648
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1648
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>         Environment: The test is done with the JBoss Portal 2.6.1.GA clustered archive with JBoss AS 4.2.1bundled. portal-ds is the default hsqldb. 
>            Reporter: Martin Putz
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> The process to reproduce the issue :
> 1- start jboss as
> 2- copy a portlet application as exploded directory to /deploy (eg. this has been tested with a helloworldportalpage.war from portletswap)
> 3- with the browser go to the portal then the new 'MyPage' page - the HelloWorldPortlet should be here
> 4- remove the portlet directory (helloworldportalpage.war from deploy/)
> 5- go to the 'MyPage' page, you should see the NullPointerException:
> java.lang.NullPointerException
> at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:79)
> at org.jboss.portal.web.jboss.JBossWebContext.include(JBossWebContext.java:61)
> at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.dispatch(AbstractRequestContext.java:81)
> at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:70)
> at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:38)
> at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
> at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:68)
> ...
> Doing these steps with the archive file (not exploded form) is working well. At step 5 you just see an empty page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 06:49:20 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:49:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1583) Permissions not
 pruned after deletion of Role
In-Reply-To: <12563377.1184593803835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13669423.1188298160136.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1583?page=all ]

Thomas Heute updated JBPORTAL-1583:
-----------------------------------

    Fix Version/s:     (was: 2.6.2 Final)

> Permissions not pruned after deletion of Role
> ---------------------------------------------
>
>                 Key: JBPORTAL-1583
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1583
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: Windows XP Professional, Jboss 4.3.0, JBoss_Portal_2_6_0 from svn
>            Reporter: Tobias Roth
>             Fix For: 2.8 Final
>
>
> Summary: When a role is deleted, it still shows up in various pwermission screens.
> How to repeat: Create a new role, assign the default portal 'view recursive' permissions for this new role, delete the role, check that permission screen for the default portal and find that the deleted role is still listed there.
> What I expected: When a role is deleted, all associated permissions are removed
> 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 lists.jboss.org  Tue Aug 28 06:53:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1534) Integrate
	netvibes widgets
In-Reply-To: <31207655.1183717973218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1993466.1188298398442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1534?page=all ]

Thomas Heute updated JBPORTAL-1534:
-----------------------------------

    Fix Version/s:     (was: 2.6.2 Final)

> Integrate netvibes widgets
> --------------------------
>
>                 Key: JBPORTAL-1534
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1534
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Widget
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>            Priority: Optional
>             Fix For: 2.8 Final
>
>
> Integrate netvibes widgets into portal- similar way google gadgets are.
> http://dev.netvibes.com/doc/howto/widget_export

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 06:53:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30975529.1188298398590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock updated JBCOMMON-31:
---------------------------------

    Component/s: core

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.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 lists.jboss.org  Tue Aug 28 06:55:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 06:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23754698.1188298518378.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock closed JBCOMMON-31.
--------------------------------

    Resolution: Done

Ported the WeakTypeCache the AbstractBuilder helper class
and a generified WeakValueHashMap.

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.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 lists.jboss.org  Tue Aug 28 06:55:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1505) Parameters class
 may have a "protected" internal Map, for overriding
In-Reply-To: <24122424.1182853276600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5505981.1188298518923.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1505?page=all ]

Thomas Heute updated JBPORTAL-1505:
-----------------------------------

    Fix Version/s:     (was: 2.6.2 Final)

> Parameters class may have a "protected" internal Map, for overriding
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1505
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1505
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 RC3
>            Reporter: Antoine Herzog
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.8 Final
>
>
> The class org.jboss.portlet.util.Parameters has a 
>        private Map parameters;
> put it with protected :
>        protected Map parameters;
> so access it possible when overriding this class.
> Example of needs : 
>        - overriding the the Parameters class to provide access to the collection, etc...
>        - use of our own TotoParameters, inheriting from Parameters, to work it with specific features
> for debugging... log what is in it (the Parameters class provide nothing to get the collection of key, the size() etc...)
> and when overriding and modifying some CommandFactory and URLFactory
> Turnaround : I use a ParametersHelper, to fill the Map of params, manipulate it, debug... 
> and just before to pass it to the portal (end of CommandFactory doMapping method), I build a Parameters instance from it.
> It is ok in this use case, but overriding the class would be much better.
> 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 lists.jboss.org  Tue Aug 28 06:55:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:55:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1525) RichFaces :
 finish integration : features, examples...
In-Reply-To: <30089601.1183547751388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18711004.1188298519225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1525?page=all ]

Thomas Heute updated JBPORTAL-1525:
-----------------------------------

    Fix Version/s: 2.6.3 Final
                       (was: 2.6.2 Final)

> RichFaces : finish integration : features, examples...
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1525
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1525
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Samples
>    Affects Versions: 2.6 CR3
>         Environment: JBoss Portal 2.6CR3 (on a JBoss AS 4.0.5)
> Rich Faces 3.0.0 and 3.0.2 (fixed version)
>            Reporter: Antoine Herzog
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.3 Final
>
>
> RichFaces has provided a sample application to work in a JBoss Portal Portlet. 
> There was quiet a lot of tuning and adaptation (RichFaces side only ?).
> It seems that it work with the JBoss Portal 2.6.0 as released.
> But they may be some things to do in JBoss Portal side.
>  - Use of RichFaces for admin portlets etc... (as it is now inside JBoss products)
>  - At least, integrate a sample RichFaces Portlet, to show how nice it is, and how it works 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 lists.jboss.org  Tue Aug 28 06:57:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 06:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499)
 CMSAdminPortlet should use
 Users/Roles Module and not direct HQL query
In-Reply-To: <19679517.1182517612791.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21355847.1188298638664.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12374136 ] 
            
Thomas Heute commented on JBPORTAL-1499:
----------------------------------------

Sohil,
could you close this case as "Won't fix" and open a new one with a correct name and description for it with the planned target release please.



> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6 Final, 2.6.1 Final
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 07:04:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 07:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1624) Create icon for
 the admin
 mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
In-Reply-To: <5089473.1186511209298.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19166353.1188299058248.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1624?page=all ]

Thomas Heute resolved JBPORTAL-1624.
------------------------------------

    Resolution: Duplicate Issue

> Create icon for the admin mode in the themes : Phalanx, Mapple, Industrial, Mission-Critical
> --------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1624
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1624
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 07:04:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 07:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1625) Portlet mode
 "admin" for portlet administration
In-Reply-To: <32179551.1186516913488.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6322085.1188299058364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1625?page=all ]

Thomas Heute resolved JBPORTAL-1625.
------------------------------------

    Resolution: Done

> Portlet mode "admin" for portlet administration
> -----------------------------------------------
>
>                 Key: JBPORTAL-1625
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1625
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6.1 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 07:12:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 07:12:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1602) IPC example
	wrong in doco
In-Reply-To: <8920649.1184862707178.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15419486.1188299538857.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1602?page=all ]

Thomas Heute reassigned JBPORTAL-1602:
--------------------------------------

    Assignee: Thomas Heute  (was: Julien Viet)

> IPC example wrong in doco
> -------------------------
>
>                 Key: JBPORTAL-1602
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1602
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> 10.8.2
>             // We can redirect
>             newEvent = new WindowActionEvent(windowB);
>             newEvent.setParameters(wae.getParameters());
>             // Redirect to the new event
>             return newEvent;
> This causes an exception regarding window state.  This should read as http://anonsvn.jboss.org/repos/portal/trunk/core-samples/src/main/org/jboss/portal/core/samples/basic/event/PortletB.java
>                // We can redirect
>                newEvent = new WindowActionEvent(windowB);
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
>    

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 08:02:35 2007
From: jira-events at lists.jboss.org (andreas kinell (JIRA))
Date: Tue, 28 Aug 2007 08:02:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1142) nested accessors
 on the lhs of
 the memberOf (or not memberOf) operator lead to an exception
Message-ID: <33222909.1188302555335.JavaMail.jira@cloud.prod.atl2.jboss.com>

nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception
-------------------------------------------------------------------------------------------

                 Key: JBRULES-1142
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1142
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  4.0.0.GA
         Environment: Windows XP, Java 1.5, Drools 4.0.0.GA
            Reporter: andreas kinell
         Assigned To: Mark Proctor


nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception:

business logic (pseudocode):

class Position {
   private Instrument instrument;
}
class Instrument {
   private Currency currency;
}

with getters and setters.

rule:

$collection : Collection()
$position : Position(instrument.currency not memberOf $collection)

exception:

org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 1f99eea
	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:212)
	at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:110)
	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:119)
	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
	at test.RuleTest.testRuleEngine1(RuleTest.java:99)
Caused by: java.lang.ClassCastException: test.Currency
	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36)
	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:206)
	... 33 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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
In-Reply-To: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13348394.1188304547622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-30?page=all ]

Adrian Brock reopened JBCOMMON-30:
----------------------------------

             

> Generify the lazy list, map and set implementations
> ---------------------------------------------------
>
>                 Key: JBCOMMON-30
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.1.GA
>
>
> Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-30) Generify the lazy
 list, map and set implementations
In-Reply-To: <22052928.1188297558206.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13765624.1188304547736.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-30?page=all ]

Adrian Brock closed JBCOMMON-30.
--------------------------------

    Fix Version/s: 2.2.1.GA
                       (was: 2.0.5.GA)
       Resolution: Done

> Generify the lazy list, map and set implementations
> ---------------------------------------------------
>
>                 Key: JBCOMMON-30
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-30
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.1.GA
>
>
> Generify the lazy collection 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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <195681.1188304547860.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock reopened JBCOMMON-31:
----------------------------------

             

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.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 lists.jboss.org  Tue Aug 28 08:35:47 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Tue, 28 Aug 2007 08:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-31) Port generic
 collections from Microcontainer to common
In-Reply-To: <5642386.1188297948068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24552930.1188304547979.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-31?page=all ]

Adrian Brock closed JBCOMMON-31.
--------------------------------

    Fix Version/s: 2.2.1.GA
                       (was: 2.0.5.GA)
       Resolution: Done

> Port generic collections from Microcontainer to common
> ------------------------------------------------------
>
>                 Key: JBCOMMON-31
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-31
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: 2.2.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 lists.jboss.org  Tue Aug 28 08:39:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Tue, 28 Aug 2007 08:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1143) ClassTypeResolver
 throws an Error
Message-ID: <29742507.1188304758286.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassTypeResolver throws an Error
---------------------------------

                 Key: JBRULES-1143
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1143
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Rule Assemply/SPI
    Affects Versions:  4.0.0.GA
            Reporter: Michael Neale
         Assigned To: Mark Proctor
            Priority: Minor
             Fix For: FUTURE


would be nicer if it was a better exception (or reported it a bit better) - perhaps. Its pretty buried.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:03:18 2007
From: jira-events at lists.jboss.org (andreas kinell (JIRA))
Date: Tue, 28 Aug 2007 09:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1142) nested
 accessors on the lhs
 of the memberOf (or not memberOf) operator lead to an exception
In-Reply-To: <33222909.1188302555335.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5013027.1188306198681.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1142?page=comments#action_12374159 ] 
            
andreas kinell commented on JBRULES-1142:
-----------------------------------------

After chatting with E.Tirelli it seems that this bug was fixed by a bugfix for a very similar issue.
see this thread regarding 'contains':
http://lists.jboss.org/pipermail/rules-users/2007-August/002356.html


> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception
> -------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1142
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1142
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.5, Drools 4.0.0.GA
>            Reporter: andreas kinell
>         Assigned To: Mark Proctor
>   Original Estimate: 5 hours
>  Remaining Estimate: 5 hours
>
> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception:
> business logic (pseudocode):
> class Position {
>    private Instrument instrument;
> }
> class Instrument {
>    private Currency currency;
> }
> with getters and setters.
> rule:
> $collection : Collection()
> $position : Position(instrument.currency not memberOf $collection)
> exception:
> org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 1f99eea
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:212)
> 	at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:110)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:119)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at test.RuleTest.testRuleEngine1(RuleTest.java:99)
> Caused by: java.lang.ClassCastException: test.Currency
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36)
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:206)
> 	... 33 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 lists.jboss.org  Tue Aug 28 09:05:18 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 28 Aug 2007 09:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4638) fix
 org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web
 2.0.1.CR6.
In-Reply-To: <14167343.1188233238869.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19486711.1188306318271.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4638?page=all ]

Remy Maucherat resolved JBAS-4638.
----------------------------------

    Resolution: Done

As with a previous problem, this was caused by new attribute validation code, which is not compatible with the SSL factories which use arbitrary attributes.

> fix org.jboss.test.web.test.ssl.SSLUnitTestCase caused by upgrade to JBoss Web 2.0.1.CR6.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-4638
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4638
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-4.2.2.GA
>
>
> see http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-sun-1.5?log=log20070821220014

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:13:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 09:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-409) Channel bundling
In-Reply-To: <24082841.1168897432592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32649403.1188306798394.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-409?page=all ]

Bela Ban updated JGRP-409:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.6)

Revisit this in 2.x. Instead of channel bundling, OS provided mechanisms such as IP Bonding could be used (needs to be verified).
Theoretically, channel bundling could increase performance, as we can partition the traffic across multiple IP multicast addresses.
If we want to do this, maybe we need to revisit logical addresses too.

> Channel bundling
> ----------------
>
>                 Key: JGRP-409
>                 URL: http://jira.jboss.com/jira/browse/JGRP-409
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>
> We can distributed traffic across multiple sockets in the transport. E.g. if we have eth0 and eth1, and both are 100Mbps *full duplex*, then we should be able to send 100Mbps on eth0 and 100Mbps on eth1 *simultaneously*.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:30:50 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:30:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1580) [PATCH] updated
 helloworld jsf portlet
In-Reply-To: <8511276.1184442783989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6944219.1188307850838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1580?page=all ]

Thomas Heute reassigned JBPORTAL-1580:
--------------------------------------

    Assignee: Thomas Heute

> [PATCH] updated helloworld jsf portlet
> --------------------------------------
>
>                 Key: JBPORTAL-1580
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1580
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Samples
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>         Attachments: helloworldportlet.zip
>
>
> I also uploaded this to portalswap but I'm not sure it is being monitored.  This is an updated version of the helloworldjsf that works on JBP 2.6+JBAS 4.2.  The previous one that was there did NOT work on the 2.6/4.2 combo.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:30:51 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:30:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1581) Update Hello
 World doc and sample to 2.6
In-Reply-To: <32326614.1184462957708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30219938.1188307851054.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1581?page=all ]

Thomas Heute reassigned JBPORTAL-1581:
--------------------------------------

    Assignee: Thomas Heute  (was: Xi HUANG)

> Update Hello World doc and sample to 2.6
> ----------------------------------------
>
>                 Key: JBPORTAL-1581
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1581
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide, Portal Samples
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> http://docs.jboss.com/jbportal/v2.6/reference-guide/html_single/#desc_examples
> "To illustrate our example, we have made available a portlet with a page descriptor that you can download here: HelloWorld Page." 
> link is http://anonsvn.jboss.org/repos/portletswap/portlets/2_4/bundles/HelloWorldPortalPage.zip
> There doesn't appear to be a 2.6 version of this and since it is trying to demonstrate descriptors that the doc illustrates have changed between 2.4/2.6 it seems bad to then reference an out of date version from the doco.  While the changes are minor, it should ref the 2.6 dtd and such.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:35:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1604) Window state
 required but has no effect
In-Reply-To: <17779748.1184893247122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21280722.1188308118323.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1604?page=all ]

Thomas Heute reassigned JBPORTAL-1604:
--------------------------------------

    Assignee: Julien Viet

> Window state required but has no effect
> ---------------------------------------
>
>                 Key: JBPORTAL-1604
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1604
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> In 2.6 you must do this
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(org.jboss.portal.WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
> when sending an event or you get an error.  However, the window state is completely ignored (the window would not be maximized with the above).  If it is required it should have some effect -- otherwise the api should revert to before where it was not 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 lists.jboss.org  Tue Aug 28 09:45:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1602) IPC example
	wrong in doco
In-Reply-To: <8920649.1184862707178.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7018398.1188308718493.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1602?page=all ]

Thomas Heute resolved JBPORTAL-1602.
------------------------------------

    Resolution: Done

> IPC example wrong in doco
> -------------------------
>
>                 Key: JBPORTAL-1602
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1602
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> 10.8.2
>             // We can redirect
>             newEvent = new WindowActionEvent(windowB);
>             newEvent.setParameters(wae.getParameters());
>             // Redirect to the new event
>             return newEvent;
> This causes an exception regarding window state.  This should read as http://anonsvn.jboss.org/repos/portal/trunk/core-samples/src/main/org/jboss/portal/core/samples/basic/event/PortletB.java
>                // We can redirect
>                newEvent = new WindowActionEvent(windowB);
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
>    

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:52:32 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:52:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1551) Improve file
 upload sample to show how to correctly build a file upload portlet
In-Reply-To: <7536863.1183996472000.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17212084.1188309152812.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1551?page=all ]

Thomas Heute reassigned JBPORTAL-1551:
--------------------------------------

    Assignee: Julien Viet

Please assign this to someone, fix this or change the fix version.

I'm not sure what is the 'correct' way :)

I'm also removing all the unassigned issues for JBoss Portal 2.6.2 (either by assigning them or postponing them)

> Improve file upload sample to show how to correctly build a file upload portlet
> -------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1551
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1551
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: FileUploadPortlet.java
>
>
> Retrieving portlet parameters the correct way is not done (cf CharsetPortlet and CMSPortlet bug JBPORTAL-1550 that was not correctly using 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 lists.jboss.org  Tue Aug 28 09:54:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1598) Properly
 support JBoss Cache 1.3.x when running on JBAS 4.2
In-Reply-To: <31296310.1184798747261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6152765.1188309258297.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1598?page=comments#action_12374169 ] 
            
Thomas Heute commented on JBPORTAL-1598:
----------------------------------------

The issue here is to keep supporting 4.0.5 (former JBoss Cache API) and 4.2 (newer JBoss Cache API) (unless we can embed the new one in both AS)

> Properly support JBoss Cache 1.3.x when running on JBAS 4.2
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1598
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1598
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> this blips up w/2.6 on 4.2:
> 2007-07-18 18:29:57,465 INFO  [org.jboss.cache.interceptors.CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 2007-07-18 18:29:57,465 INFO  [org.jboss.cache.interceptors.CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:54:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:54:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1600) inherit
 security constraint between portal Template and dashboards
In-Reply-To: <17178120.1184859228977.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17858199.1188309259136.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1600?page=all ]

Thomas Heute reassigned JBPORTAL-1600:
--------------------------------------

    Assignee: Thomas Heute

> inherit security constraint between portal Template and dashboards
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1600
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1600
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Lionel ROSIER
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> we can apply security settings on the template portal, particularly  on the pages.
> but the security constraints are not inherit from the portal Template to the dashboards.
> a page which is secured with a role in the portal template is visible by every users in their dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 09:58:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1560) pass
 lang/region information
 when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
In-Reply-To: <1693847.1184003024746.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21596683.1188309498812.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1560?page=all ]

Thomas Heute reassigned JBPORTAL-1560:
--------------------------------------

    Assignee: Boleslaw Dawidowicz

> pass lang/region information when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1560
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1560
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 09:58:19 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 09:58:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1588) Portlet
 instance list should
 "scroll" to the appropriate instance when a new instance is inserted in the
 list outside of the initial range
In-Reply-To: <20605356.1184641847020.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10579981.1188309499945.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1588?page=all ]

Thomas Heute reassigned JBPORTAL-1588:
--------------------------------------

    Assignee: Chris Laprun

> Portlet instance list should "scroll" to the appropriate instance when a new instance is inserted in the list outside of the initial range
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1588
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1588
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6 Final, 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Tue Aug 28 10:04:18 2007
From: jira-events at lists.jboss.org (Felipe (JIRA))
Date: Tue, 28 Aug 2007 10:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
Message-ID: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>

message parts with the atribute element won't be accepted by bpel
-----------------------------------------------------------------

                 Key: BPEL-277
                 URL: http://jira.jboss.com/jira/browse/BPEL-277
             Project: JBoss jBPM BPEL
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: jBPM BPEL 1.1 beta 3
         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
            Reporter: Felipe
         Assigned To: Alejandro Guizar


Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )

However, when using the following definitions:
<element name="EE">
  <complexType>
     <sequence>
        <element name="usuario" type="xsd:string"/>
        <element name="sistema" type="xsd:string"/>
     </sequence>
   </complexType>
</element>

<wsdl:message name="pruebaE">
      <wsdl:part name="entrada" element="tns1:EE"/>
</wsdl:message>

<variable name="entradaPruebaE" messageType="BA:pruebaE"/>
    
<copy>
      	<from variable="nombres" />
      	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
 </copy>

It will throw the following exception:
2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
        at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
        at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)

In the addressed part of XPathEvaluator, the following can be read:
  if (!(node instanceof Element)) {
      // cannot create node for a non-element parent
      throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
    }

This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 10:06:39 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 10:06:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-407) Migrate
 microcontainer docbook gen to jdocbook plugin
In-Reply-To: <26415361.1187899278199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8634052.1188309999009.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-407?page=all ]

Paul Gier closed JBBUILD-407.
-----------------------------

    Resolution: Done

Microcontainer build is now using jdocbook plugin.

> Migrate microcontainer docbook gen to jdocbook plugin
> -----------------------------------------------------
>
>                 Key: JBBUILD-407
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-407
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Microcontainer should use the maven-jdocbook-plugin for it's doc generation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 10:11:19 2007
From: jira-events at lists.jboss.org (Dawie Malan (JIRA))
Date: Tue, 28 Aug 2007 10:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1018)
 ClassCastException on
 concurrent EJB3 method invocation from different beans
In-Reply-To: <21528878.1185176830278.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2163664.1188310279308.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1018?page=comments#action_12374175 ] 
            
Dawie Malan commented on EJBTHREE-1018:
---------------------------------------

I see this issue is not assigned yet.  It is a showstopper for us, as we are running multiple JBoss servers and are planning an even bigger installation.  This issue may force us to rethink our architecture if a solution is not found in time. I would appreciate it if it could be scheduled so that we have more or less an idea of how long it is going to remain a problem.

Thanks!

> ClassCastException on concurrent EJB3 method invocation from different beans
> ----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1018
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1018
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA, AS 4.2.1.GA
>         Environment: Java: JDK 1.5.0_11
> Eclipse: SDK 3.2.2
>            Reporter: Michael Pfeiffer
>         Attachments: deployables.zip, jboss.example.src.zip
>
>
> Two different EJB3 stateless session beans A and B packaged into separate EAR files deployed on the same JBoss instance 
> invoke a method of another stateless session bean C on another JBoss instance that returns an object of a user 
> defined class Value.
> There seems to be a multi-threading issue. 
> Sometimes when both beans concurrently call the method of C an ClassCastException Value is thrown within the remote 
> interface proxy before the result object is returned to the calling bean.
> The class Value and the remote interface for C are packaged into a JAR file within each EAR file inside a "lib" folder.
> If this JAR file is deployed instead and not packaged into the EAR files of bean A and B everything 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 lists.jboss.org  Tue Aug 28 10:52:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 10:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25645866.1188312738614.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374186 ] 
            
Dimitris Andreadis commented on JBAS-4562:
------------------------------------------

Removed ehcache and jbpm.

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 10:58:39 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 10:58:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-189) Validate that IP
 Bonding is supported
Message-ID: <5058543.1188313119880.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-189?page=all ]

Bela Ban updated JGRP-189:
--------------------------

    Fix Version/s: 2.6
                       (was: 2.x)

> Validate that IP Bonding is supported
> -------------------------------------
>
>                 Key: JGRP-189
>                 URL: http://jira.jboss.com/jira/browse/JGRP-189
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8, 2.2.9, 2.2.9.1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> Linux specific

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:08:18 2007
From: jira-events at lists.jboss.org (Boleslaw Dawidowicz (JIRA))
Date: Tue, 28 Aug 2007 11:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1560) pass
 lang/region information
 when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
In-Reply-To: <1693847.1184003024746.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26419167.1188313698971.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1560?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1560.
-------------------------------------------

    Resolution: Done

done

> pass lang/region information when looking for gadgets ('gmodules.com/ig/directory?lang=fr&country=ca')
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1560
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1560
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 11:08:20 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 11:08:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-105) GossipRouter should
 additionally listen on IP multicast group and bridge traffic
Message-ID: <14453874.1188313700257.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-105?page=all ]

Bela Ban updated JGRP-105:
--------------------------

    Fix Version/s: 2.7
                       (was: 2.6)

> GossipRouter should additionally listen on IP multicast group and bridge traffic
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-105
>                 URL: http://jira.jboss.com/jira/browse/JGRP-105
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.7
>
>
> GossipRouter should be augmented to not just route traffic between TCP endpoints, but also between an IP multicast group and all TCP endpoints.
> It should be configured with the properties for a (multicast-based) group X, and then forward messages from X to all of its attached endpoints, and vice versa.
> In the future, this concept could be extended to generic bridging functionality, which will allow to construct hierarchical messaging trees, similar to the MBone

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:08:20 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 11:08:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-430) Support accessing
 multiple GossipRouters in TUNNEL
In-Reply-To: <16193776.1173523767661.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8786170.1188313700445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-430?page=all ]

Bela Ban updated JGRP-430:
--------------------------

    Fix Version/s: 2.7
                       (was: 2.6)

> Support accessing multiple GossipRouters in TUNNEL
> --------------------------------------------------
>
>                 Key: JGRP-430
>                 URL: http://jira.jboss.com/jira/browse/JGRP-430
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.7
>
>
> Multiple GossipRouters can only be used for lookups, not for routing... However, since all traffic to the GR goes out via TUNNEL (as JGroups transport), and TUNNEL uses a RouterStub to send a message to the GR, we could do the following:
>    * the RouterStub is currently configured with the address of *one* GR
>    * a Stub.send() succeeds in connecting to the GR and sending the
>      message, or goes into a state where it tries to reconnect *forever*
>    * I could simply change that to configure the RouterStub with
>      multiple GRs:
>          o for send(), we iterate through the GRs until send() returns
>            true 
> EFFECT: a GossipRouter is not a single point of failure any longer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:10:18 2007
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Aug 2007 11:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAOP-433) Caller Interceptor
 Chains Are Not Rebuilt
In-Reply-To: <1733027.1183437963987.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27730156.1188313818756.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-433?page=all ]

Kabir Khan reassigned JBAOP-433:
--------------------------------

    Assignee: Flavia Rainone

> Caller Interceptor Chains Are Not Rebuilt
> -----------------------------------------
>
>                 Key: JBAOP-433
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-433
>             Project: JBoss AOP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.5.GA, 2.0.0.alpha5
>            Reporter: Flavia Rainone
>         Assigned To: Flavia Rainone
>            Priority: Critical
>             Fix For: 1.5.6.GA, 2.0.0.beta
>
>
> The rebuild process of interceptor chains for caller pointcuts is not taking place correctly: no pointcut rematching is being performed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:10:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:10:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-294) Create hudson
 instance for maven build in app server head.
Message-ID: <22220967.1188313819118.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-294?page=all ]

Paul Gier updated JBBUILD-294:
------------------------------

        Summary: Create hudson instance for maven build in app server head.  (was: Create cruisecontrol instance for maven build in app server head.)
    Description: Setup a hudson instance for Maven.  (was: Setup a cruise control instance for Maven.)

> Create hudson instance for maven build in app server head.
> ----------------------------------------------------------
>
>                 Key: JBBUILD-294
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-294
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>    Affects Versions: Maven Build 1.1
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>
> Setup a hudson instance for Maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:12:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:12:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-294) Create hudson
 instance for maven build in app server head.
Message-ID: <23123521.1188313939570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-294?page=all ]

Paul Gier updated JBBUILD-294:
------------------------------

     Original Estimate: 2 days
    Remaining Estimate: 2 days

> Create hudson instance for maven build in app server head.
> ----------------------------------------------------------
>
>                 Key: JBBUILD-294
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-294
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>    Affects Versions: Maven Build 1.1
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Setup a hudson instance for Maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:12:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:12:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-409) Fix microcontainer
	jdk14 tests.
In-Reply-To: <12323051.1187986218403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19495009.1188313939773.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-409?page=all ]

Paul Gier updated JBBUILD-409:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Fix microcontainer jdk14 tests.
> -------------------------------
>
>                 Key: JBBUILD-409
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-409
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven, JBossRetro
>            Reporter: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Many of the retro build tests for microcontainer are failing.  These are mostly caused by missing features of jboss-retro.  Once the relevant retro issues have been resolved, the tests should be checked again to find remaining 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 lists.jboss.org  Tue Aug 28 11:14:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-408) Figure out a way
 to use alternate pom files in modules.
In-Reply-To: <1559246.1187985875287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3054428.1188314058253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-408?page=all ]

Paul Gier updated JBBUILD-408:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Figure out a way to use alternate pom files in modules.
> -------------------------------------------------------
>
>                 Key: JBBUILD-408
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-408
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Currently the jdk14 builds have to be done as separate modules, because maven is not able to use alternate files (pom-jdk14.xml) in modules.
> This issue has been created to address this in maven: http://jira.codehaus.org/browse/MNG-3150
> Until this issue is resolved, maybe an ant script can be created to build the modules as an aggregate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:14:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 11:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-410) Set up retro
 jdk1.4 build and test of microcontainer on hudson.
In-Reply-To: <17193616.1187986589124.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32755936.1188314058404.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-410?page=all ]

Paul Gier updated JBBUILD-410:
------------------------------

    Fix Version/s: Maven Build - Maint 2007
                       (was: Maven Build - App Server)

> Set up retro jdk1.4 build and test of microcontainer on hudson.
> ---------------------------------------------------------------
>
>                 Key: JBBUILD-410
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-410
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> A retro build of microcontainer should be set up on hudson so that we can see which tests are failing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:24:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Aug 2007 11:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-564) Unicast from within
 viewAccepted() callback throws exception in UNICAST
In-Reply-To: <10247822.1184996987287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10012507.1188314658307.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-564?page=all ]

Bela Ban updated JGRP-564:
--------------------------

    Fix Version/s: 2.5.1

> Unicast from within viewAccepted() callback throws exception in UNICAST
> -----------------------------------------------------------------------
>
>                 Key: JGRP-564
>                 URL: http://jira.jboss.com/jira/browse/JGRP-564
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>
> Unit test is UnicastUnitTest.testUnicastMessageInCallbackExistingMember(). Swapping lines 505 and 506 in GMS fixes the issue. Stack trace is below.
> The issue is that - since we propagate the new view up the stack first, then down - the viewAccepted() callback gets invoked first, before UNICAST can update its view (done when the new view is propagated down the stack).
> We need to investigate whether swapping lines 505 and 506 breaks JGRP-347
> 7:45:12,375 [WARN] [Incoming Thread,x,192.168.5.2:1959] JChannel.up(): failed calling viewAccepted() in receiver
> java.lang.RuntimeException: java.lang.IllegalArgumentException: 192.168.5.2:1961 is not a member of the group [192.168.5.2:1959] (enabled_members=[])
> 	at org.jgroups.tests.UnicastUnitTest$MyReceiver.viewAccepted(UnicastUnitTest.java:84)
> 	at org.jgroups.JChannel.up(JChannel.java:1099)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:325)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:151)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
> 	at org.jgroups.protocols.FC.up(FC.java:414)
> 	at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:505)
> 	at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:449)
> 	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:661)
> 	at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:160)
> 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> 	at org.jgroups.protocols.UNICAST.up(UNICAST.java:263)
> 	at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:720)
> 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:546)
> 	at org.jgroups.protocols.BARRIER.up(BARRIER.java:122)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
> 	at org.jgroups.protocols.FD.up(FD.java:322)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:298)
> 	at org.jgroups.protocols.MERGE2.up(MERGE2.java:145)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:247)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1486)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1435)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> 	at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:34:23 2007
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 28 Aug 2007 11:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-975) HA-JNDI
 InitialContext for @Resource annotation
In-Reply-To: <8059294.1180541948420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24583361.1188315263022.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-975?page=all ]

Shelly McGowan reassigned EJBTHREE-975:
---------------------------------------

    Assignee: Shelly McGowan  (was: William DeCoste)

> HA-JNDI InitialContext for @Resource annotation
> -----------------------------------------------
>
>                 Key: EJBTHREE-975
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-975
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Ana Holzbach
>         Assigned To: Shelly McGowan
>             Fix For: AS 4.2.2.GA
>
>
>  We're deploying ejbs in a clustered environment that access JMS topics with @Resource annotation as follows:
>         @Resource(mappedName = "TopicConnectionFactory")
> 	private ConnectionFactory mJmsConnectionFactory;
> 	
> 	@Resource(mappedName = "topic/RoomService/BedStaffUpdate")
> 	private Topic mStaffUpdateTopic; 
>  The topics are deployed in deploy-hasingleton and are available to the singleton master in the cluster only. The remaining nodes get the following error:
>  javax.naming.NameNotFoundException: topic 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:267)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at flex.messaging.services.messaging.adapters.JMSProxy.getDestination(JMSProxy.java:186)
> at flex.messaging.services.messaging.adapters.JMSTopicConsumer.start(JMSTopicConsumer.java:59)
> at flex.messaging.services.messaging.adapters.JMSAdapter.manage(JMSAdapter.java:345)
> at flex.messaging.services.MessageService.manageSubscriptions(MessageService.java:571)
> at flex.messaging.services.MessageService.serviceCommand(MessageService.java:152)
> at flex.messaging.MessageBroker.routeCommandToService(MessageBroker.java:622)
> at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:298)
> at flex.messaging.endpoints.rtmp.AbstractRTMPServer.dispatchMessage(AbstractRTMPServer.java:682)
> at flex.messaging.endpoints.rtmp.NIORTMPConnection$RTMPReader.run(NIORTMPConnection.java:665)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
> or.java:643)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> ava:668)
> at java.lang.Thread.run(Thread.java:595)	
>  See also http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049784#4049784
>  According to Brian Stansberry the @Resource annotations are resolved relative to a default initial context, which will not work for the clustered environment, since we need access to the HA-JNDI context for these. Also according to Brian, getJndiProperties() in DeploymentUnit should be responsible for reading jndi properties defined at deployment through which we might be able to define an HA-JNDI context, but this method returns null in jboss 4.x and also in "2 out of the 3 impls in the AS 5 codebase". See also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109219

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:34:23 2007
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 28 Aug 2007 11:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-975) HA-JNDI
 InitialContext for @Resource annotation
In-Reply-To: <8059294.1180541948420.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30066155.1188315263355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-975?page=all ]

Shelly McGowan reassigned EJBTHREE-975:
---------------------------------------

    Assignee: William DeCoste  (was: Shelly McGowan)

intended to reassign the JBPAPP related issue

> HA-JNDI InitialContext for @Resource annotation
> -----------------------------------------------
>
>                 Key: EJBTHREE-975
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-975
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Ana Holzbach
>         Assigned To: William DeCoste
>             Fix For: AS 4.2.2.GA
>
>
>  We're deploying ejbs in a clustered environment that access JMS topics with @Resource annotation as follows:
>         @Resource(mappedName = "TopicConnectionFactory")
> 	private ConnectionFactory mJmsConnectionFactory;
> 	
> 	@Resource(mappedName = "topic/RoomService/BedStaffUpdate")
> 	private Topic mStaffUpdateTopic; 
>  The topics are deployed in deploy-hasingleton and are available to the singleton master in the cluster only. The remaining nodes get the following error:
>  javax.naming.NameNotFoundException: topic 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:267)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at flex.messaging.services.messaging.adapters.JMSProxy.getDestination(JMSProxy.java:186)
> at flex.messaging.services.messaging.adapters.JMSTopicConsumer.start(JMSTopicConsumer.java:59)
> at flex.messaging.services.messaging.adapters.JMSAdapter.manage(JMSAdapter.java:345)
> at flex.messaging.services.MessageService.manageSubscriptions(MessageService.java:571)
> at flex.messaging.services.MessageService.serviceCommand(MessageService.java:152)
> at flex.messaging.MessageBroker.routeCommandToService(MessageBroker.java:622)
> at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:298)
> at flex.messaging.endpoints.rtmp.AbstractRTMPServer.dispatchMessage(AbstractRTMPServer.java:682)
> at flex.messaging.endpoints.rtmp.NIORTMPConnection$RTMPReader.run(NIORTMPConnection.java:665)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
> or.java:643)
> at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> ava:668)
> at java.lang.Thread.run(Thread.java:595)	
>  See also http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049784#4049784
>  According to Brian Stansberry the @Resource annotations are resolved relative to a default initial context, which will not work for the clustered environment, since we need access to the HA-JNDI context for these. Also according to Brian, getJndiProperties() in DeploymentUnit should be responsible for reading jndi properties defined at deployment through which we might be able to define an HA-JNDI context, but this method returns null in jboss 4.x and also in "2 out of the 3 impls in the AS 5 codebase". See also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109219

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 11:34:24 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Tue, 28 Aug 2007 11:34:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10827162.1188315264729.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=all ]

Andrew Rubinger reassigned EJBTHREE-1025:
-----------------------------------------

    Assignee: Andrew Rubinger  (was: William DeCoste)

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Andrew Rubinger
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 12:02:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 12:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1649) Update
 installation instruction for JBoss AS 4.2.1.GA
Message-ID: <26456958.1188316938512.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update installation instruction for JBoss AS 4.2.1.GA
-----------------------------------------------------

                 Key: JBPORTAL-1649
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1649
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
            Reporter: Thomas Heute
         Assigned To: Thomas Heute
             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 12:08:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 12:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1649) Update
 installation instruction for JBoss AS 4.2.1.GA
In-Reply-To: <26456958.1188316938512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22540806.1188317298716.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1649?page=all ]

Thomas Heute resolved JBPORTAL-1649.
------------------------------------

    Resolution: Done

> Update installation instruction for JBoss AS 4.2.1.GA
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1649
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1649
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 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 lists.jboss.org  Tue Aug 28 12:10:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 12:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-259) Migrate AOP builds
	to maven
Message-ID: <15523059.1188317418302.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-259?page=all ]

Paul Gier updated JBBUILD-259:
------------------------------

    Remaining Estimate: 1 week  (was: 3 days)

> Migrate AOP builds to maven
> ---------------------------
>
>                 Key: JBBUILD-259
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-259
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>          Time Spent: 1 day
>  Remaining Estimate: 1 week
>
> Migrate AOP builds to maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:14:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 13:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4641) Move
 XMLJUnitMultipleResultFormatter from testsuite module to test module
Message-ID: <184925.1188321258850.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move XMLJUnitMultipleResultFormatter from testsuite module to test module
-------------------------------------------------------------------------

                 Key: JBAS-4641
                 URL: http://jira.jboss.com/jira/browse/JBAS-4641
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-4.2.2.GA


In Branch_4_2, this class is located in the testsuite module rather than in test.  In trunk it's in the jboss-test.jar, so logically it belongs in the test module in Branch_4_2.

I need this class to get separate reports of the same EJB3 test under different configs (see EJBTHREE-856).  The EJB3 testsuite setup that tries to use the std ant XMLJUnitResultFormatter with different "extension" attribute values doesn't work.  I don't want to add the testsuite module to the junit task classpath in EJB3; that could have too many unintended side effects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:22:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4642) Fix
 org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase
Message-ID: <32409682.1188321738616.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase
------------------------------------------------------

                 Key: JBAS-4642
                 URL: http://jira.jboss.com/jira/browse/JBAS-4642
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Scott M Stark
             Fix For:  JBossAS-5.0.0.Beta3


The error message doesn't look very helpful:

testJavaBeanSchemaInitializerInterceptor Failure description expected:<...eanSchemaInitializer[ ]> but was:<...eanSchemaInitializer[]>
junit.framework.ComparisonFailure: description expected:<...eanSchemaInitializer[
   ]> but was:<...eanSchemaInitializer[]>
	at org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase.testJavaBeanSchemaInitializerInterceptor(XMBean2UnitTestCase.java:129)
 

log snipet
...
2007-08-28 20:02:49,906 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://apache.org/xml/features/validation/dynamic set to: true
2007-08-28 20:02:49,906 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Using parser: org.apache.xerces.jaxp.SAXParserImpl at c79809, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Created parser: org.apache.xerces.jaxp.SAXParserImpl at 1ce784b, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://xml.org/sax/features/validation set to: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://xml.org/sax/features/namespaces set to: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://apache.org/xml/features/validation/dynamic set to: true
2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Using parser: org.apache.xerces.jaxp.SAXParserImpl at 1ce784b, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.DescriptorSupportContainer] addChild, {urn:jboss-test:xmbean:2.0}interceptors,org.jboss.mx.metadata.xb.InterceptorsHolder at 9934d4
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanConstructorInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,JNDIBindingService
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanConstructorInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The default no-arg constructor
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, access,read-write
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The root JNDI name of the context the bindings
      are to be added under
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,RootName
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}type,java.lang.String
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, access,read-write
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The JNDI bindings to add under the RootName
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,Bindings
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}type,org.jboss.naming.JNDIBindings
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, impact,ACTION_INFO
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The start lifecycle operation
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,start
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}return-type,void
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, impact,ACTION_INFO
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The stop lifecycle operation
2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,stop
2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}return-type,void
2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanNotificationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The bind event notification
2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanNotificationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,bindEvent
2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] testJavaBeanSchemaInitializerInterceptor took 750ms
2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] ==== Stopping testJavaBeanSchemaInitializerInterceptor ====
2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] ==== tornDown org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase ====
...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:26:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
Message-ID: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
-----------------------------------------------------------

                 Key: JBAS-4643
                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Alexey Loubyansky
             Fix For:  JBossAS-5.0.0.Beta3


testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)

 9.162 
testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)

 2.797 
testJBossCmpJdbc Success  0.994 
testWebXml Success  1.930 
testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)

 0.455 
testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)

 0.635 
testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)

 0.825 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:28:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
In-Reply-To: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9735873.1188322098718.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4643?page=comments#action_12374239 ] 
            
Dimitris Andreadis commented on JBAS-4643:
------------------------------------------

While there, there also 2 failures in:

org.jboss.test.xml.ExtendedByImportUnitTestCase
testExtended Error Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/ExtendedByImportUnitTestCase.xml at 6,62
org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/ExtendedByImportUnitTestCase.xml at 6,62
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:184)
	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
	at org.jboss.test.xml.JBossXBTestDelegate.unmarshal(JBossXBTestDelegate.java:118)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:119)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:106)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:72)
	at org.jboss.test.xml.ExtendedByImportUnitTestCase.testExtended(ExtendedByImportUnitTestCase.java:55)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: java.lang.ClassCastException: java.lang.String
	at org.jboss.kernel.plugins.deployment.xml.BeanPropertyInterceptor.add(BeanPropertyInterceptor.java:48)
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:1197)
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:248)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:374)
	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
	at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(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:180)
	... 25 more

 
and

org.jboss.test.xml.SingletonSchemaBindingResolverUnitTestCase
testBean Error Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/SingletonSchemaBindingResolverUnitTestCaseContainerStrictBean.xml at 4,2
org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/testsuite/output/resources/org/jboss/test/xml/SingletonSchemaBindingResolverUnitTestCaseContainerStrictBean.xml at 4,2
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:184)
	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
	at org.jboss.test.xml.JBossXBTestDelegate.unmarshal(JBossXBTestDelegate.java:118)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:119)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:106)
	at org.jboss.test.xml.AbstractJBossXBTest.unmarshal(AbstractJBossXBTest.java:72)
	at org.jboss.test.xml.SingletonSchemaBindingResolverUnitTestCase.testBean(SingletonSchemaBindingResolverUnitTestCase.java:53)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI=dummy://www.jboss.org/container location=null
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:283)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:402)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
	at org.apache.xerces.xinclude.XIncludeHandler.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:180)
	... 25 more

 

> Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
> -----------------------------------------------------------
>
>                 Key: JBAS-4643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
> junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)
>  9.162 
> testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
> junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)
>  2.797 
> testJBossCmpJdbc Success  0.994 
> testWebXml Success  1.930 
> testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
> junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)
>  0.455 
> testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
> junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)
>  0.635 
> testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
> junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)
>  0.825 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 13:34:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 28 Aug 2007 13:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4644) fix
 org.jboss.test.webservice.jbws309.JBWS309TestCase(JACC) - 5 errors
Message-ID: <9681728.1188322458268.JavaMail.jira@cloud.prod.atl2.jboss.com>

fix org.jboss.test.webservice.jbws309.JBWS309TestCase(JACC) - 5 errors
----------------------------------------------------------------------

                 Key: JBAS-4644
                 URL: http://jira.jboss.com/jira/browse/JBAS-4644
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For:  JBossAS-5.0.0.Beta3


Problem appears either as:

testRoleSecuredServiceAccess Error Call invocation failed; nested exception is: java.io.IOException: Could not transmit message
java.rmi.RemoteException: Call invocation failed; nested exception is: 
	java.io.IOException: Could not transmit message
	at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:536)
	at org.jboss.ws.core.jaxrpc.client.CallImpl.invoke(CallImpl.java:277)
	at org.jboss.ws.core.jaxrpc.client.PortProxy.invoke(PortProxy.java:151)
	at $Proxy4.getContactInfo(Unknown Source)
	at org.jboss.test.webservice.jbws309.JBWS309TestCase.testRoleSecuredServiceAccess(JBWS309TestCase.java:190)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: java.io.IOException: Could not transmit message
	at org.jboss.ws.core.client.RemotingConnectionImpl.invoke(RemotingConnectionImpl.java:204)
	at org.jboss.ws.core.client.SOAPRemotingConnection.invoke(SOAPRemotingConnection.java:77)
	at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:337)
	at org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:517)
	... 25 more
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:332)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:135)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
	at org.jboss.remoting.Client.invoke(Client.java:1550)
	at org.jboss.remoting.Client.invoke(Client.java:530)
	at org.jboss.ws.core.client.RemotingConnectionImpl.invoke(RemotingConnectionImpl.java:183)
	... 28 more
Caused by: org.jboss.ws.WSException: Invalid HTTP server response [401] - Unauthorized
	at org.jboss.ws.core.soap.SOAPMessageUnMarshaller.read(SOAPMessageUnMarshaller.java:77)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:472)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:304)
	... 33 more

Or

testRoleSecuredSLSB Error SecurityException; nested exception is: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
java.rmi.AccessException: SecurityException; nested exception is: 
	javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
	at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:388)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:136)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:640)
	at org.jboss.ejb.Container.invoke(Container.java:1006)
	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.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:230)
	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 javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
	at $Proxy14.invoke(Unknown Source)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
Caused by: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:212)
	at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:152)
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
	at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
	at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:524)
	at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:458)
	at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:353)
	at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:317)
	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:185)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invokeHome(PreSecurityInterceptor.java:140)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:640)
	at org.jboss.ejb.Container.invoke(Container.java:1006)
	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.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:230)
	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 javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
	at $Proxy14.invoke(Unknown Source)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
	at org.jboss.remoting.Client.invoke(Client.java:1550)
	at org.jboss.remoting.Client.invoke(Client.java:530)
	at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:161)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:244)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:181)
	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:86)
	at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
	at $Proxy1.create(Unknown Source)
	at org.jboss.test.webservice.jbws309.JBWS309TestCase.testRoleSecuredSLSB(JBWS309TestCase.java:93)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)

 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:40:20 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 15:40:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26805821.1188330020416.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4619?page=all ]

Anil Saldhana reassigned JBAS-4619:
-----------------------------------

    Assignee: Anil Saldhana  (was: Scott M Stark)

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:42:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 15:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9327541.1188330138474.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4619?page=all ]

Anil Saldhana updated JBAS-4619:
--------------------------------

    Fix Version/s: JBossAS-4.2.2.GA

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.2.2.GA
>
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:42:18 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 15:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30990735.1188330138751.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4619?page=all ]

Anil Saldhana updated JBAS-4619:
--------------------------------

    Affects Version/s: JBossAS-4.2.1.GA
                       JBossAS-4.2.0.GA

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.2.2.GA
>
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:47:23 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4645) Fix
 org.jboss.test.web.test.ClusteredSingleSignOnUnitTestCase
Message-ID: <20045340.1188330443085.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.web.test.ClusteredSingleSignOnUnitTestCase
-------------------------------------------------------------

                 Key: JBAS-4645
                 URL: http://jira.jboss.com/jira/browse/JBAS-4645
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:49:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
Message-ID: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
------------------------------------------------------------------------

                 Key: JBAS-4646
                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:51:21 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
In-Reply-To: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <445831.1188330681457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4646?page=all ]

Brian Stansberry updated JBAS-4646:
-----------------------------------

    Fix Version/s: JBossAS-4.2.1.GA

This needs to be fixed for a release that can go in JBoss 5.

> Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4646
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.2.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 lists.jboss.org  Tue Aug 28 15:51:22 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:51:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
In-Reply-To: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19510261.1188330682670.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4646?page=all ]

Brian Stansberry updated JBAS-4646:
-----------------------------------

    Comment: was deleted

> Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4646
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.2.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 lists.jboss.org  Tue Aug 28 15:53:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4646) Fix
 org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
In-Reply-To: <18527117.1188330558286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19342089.1188330798318.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4646?page=all ]

Brian Stansberry updated JBAS-4646:
-----------------------------------

    Fix Version/s:     (was: JBossAS-4.2.1.GA)

Editing wrong JIRA.

> Fix org.jboss.test.cluster.multicfg.web.field.test.StateTransferTestCase
> ------------------------------------------------------------------------
>
>                 Key: JBAS-4646
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4646
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 15:53:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 15:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1170) Partial state
 transfer fails when multiple regions present
In-Reply-To: <5358429.1187970318264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12060861.1188330798503.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1170?page=all ]

Brian Stansberry updated JBCACHE-1170:
--------------------------------------

    Fix Version/s: 2.1.0.GA

This needs to be fixed in time for a release to integrate in AS 5.0.0.CR1.

> Partial state transfer fails when multiple regions present
> ----------------------------------------------------------
>
>                 Key: JBCACHE-1170
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1170
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> The partial state transfer mechanism is getting confused about the Fqn of the region being transferred.  
> Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase.  Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state:
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call.  Using region /JSESSION/localhost/http-field
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream
> 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state
> The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all.
> Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal.  Two problems:
> 1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly.
> 2) Need to ensure that the right Fqn gets written.  In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything.  If not, just cleaning up the ThreadLocal should 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 lists.jboss.org  Tue Aug 28 16:16:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 16:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16618213.1188332178867.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374285 ] 
            
Alejandro Guizar commented on BPEL-277:
---------------------------------------

The representation of a part P1 defined with a type T is an element with a null namespace URI and a local name equal to the name of P1.
Conversely, the representation of a part P2 defined with an element E is an element with a qualified name equal to the qualified name of E.

Your query is written as if part "entrada" was defined with a type, hence the bpel:selectionFailure fault. Try this:

<copy>
       <from variable="nombres" />
       <to variable="entradaPruebaElectrica" part="entrada" query="/tns1:EE/usuario"/>
 </copy>

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 16:25:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 16:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22998788.1188332718262.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374287 ] 
            
Alejandro Guizar commented on BPEL-277:
---------------------------------------

Alternatively, if you have a BPEL 2 process, the location path can be relative:

<copy>
       <from variable="nombres" />
       <to variable="entradaPruebaElectrica" part="entrada" query="usuario"/>
 </copy>

In fact, in jBPM BPEL this works in BPEL 1.1 processes as well, but we do not recommend it because the specification mandates absolute location paths.

You can find examples of BPEL 2 processes created using the Eclipse BPEL designer in our CVS repository: http://fisheye.jboss.com/browse/JBPM/jbpm.3/bpel/examples
In each example process, look for subdirectory src/main/bpel2.

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 16:46:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1030) Updated JBM
 to use new patched JBoss remoting jar
In-Reply-To: <11490984.1186597669494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9961628.1188333978476.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1030?page=all ]

Clebert Suconic reassigned JBMESSAGING-1030:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Updated JBM to use new patched JBoss remoting jar
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1030
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1030
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Update JBM to use new patched jar which resolves all known remoting 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 lists.jboss.org  Tue Aug 28 16:46:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1030) Updated JBM to
 use new patched JBoss remoting jar
In-Reply-To: <11490984.1186597669494.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13549267.1188333978726.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1030?page=all ]

Clebert Suconic closed JBMESSAGING-1030.
----------------------------------------

    Resolution: Done

> Updated JBM to use new patched JBoss remoting jar
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1030
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1030
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Update JBM to use new patched jar which resolves all known remoting 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 lists.jboss.org  Tue Aug 28 16:50:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
Message-ID: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>

Oracle Persistence hits a driver bug on binding blobs
-----------------------------------------------------

                 Key: JBMESSAGING-1060
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR2
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2


PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...

We will work around the 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 lists.jboss.org  Tue Aug 28 16:52:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32748280.1188334338504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1060?page=all ]

Clebert Suconic updated JBMESSAGING-1060:
-----------------------------------------

    Priority: Blocker  (was: Major)

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Tue Aug 28 16:56:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 16:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14816021.1188334578266.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1060?page=all ]

Clebert Suconic closed JBMESSAGING-1060.
----------------------------------------

    Resolution: Done

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Tue Aug 28 17:08:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 17:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-411) Create basic pom
 structure for jbossas
Message-ID: <1158519.1188335298270.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create basic pom structure for jbossas
--------------------------------------

                 Key: JBBUILD-411
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-411
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
         Assigned To: Paul Gier
             Fix For: Maven Build - App Server


The first step in as mavenization should be to create basic poms with dependency listings in each module.
Also a parent pom should be created in the build directory, and possibly an aggregator pom in the root directory.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:10:21 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 28 Aug 2007 17:10:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-258) Create functional
 pom for each module in head
Message-ID: <5720052.1188335421952.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-258?page=all ]

Paul Gier updated JBBUILD-258:
------------------------------

        Summary: Create functional pom for each module in head  (was: Create Pom file for each module in head)
    Description: A working pom should be created for each as module.  This means all main and test code compiles, tests run where applicable, and appropriate artifacts (jars, etc) are generated.  (was: Need to port the pom files from from the svn copy over to head.   Will need to update the pom's with recent changes made by developers.

(e.g. recent changes to webservice))

> Create functional pom for each module in head
> ---------------------------------------------
>
>                 Key: JBBUILD-258
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-258
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Ruel Loehr
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> A working pom should be created for each as module.  This means all main and test code compiles, tests run where applicable, and appropriate artifacts (jars, etc) are generated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:20:18 2007
From: jira-events at lists.jboss.org (Meriah Garrett (JIRA))
Date: Tue, 28 Aug 2007 17:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-235) Redesign LnF for
 SplitTopicView
In-Reply-To: <31523841.1179413935752.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2299880.1188336018915.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-235?page=all ]

Meriah Garrett resolved JBFORUMS-235.
-------------------------------------

    Resolution: Done

> Redesign LnF for SplitTopicView 
> --------------------------------
>
>                 Key: JBFORUMS-235
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-235
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum View Layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Meriah Garrett
>             Fix For: 1.0.1 RC
>
>
> Redesign the page view based on the new forums look and feel. Look for usability wins in the process.
> SplitTopicView available here : http://forums.proto.jboss.com:8080/portal/auth/portal/default/Forum/Forums?action=1&v=o&t=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 lists.jboss.org  Tue Aug 28 17:22:18 2007
From: jira-events at lists.jboss.org (Meriah Garrett (JIRA))
Date: Tue, 28 Aug 2007 17:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-229) Redesign LnF for
 Moderator Panel
In-Reply-To: <23022146.1178124330179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25473876.1188336138382.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-229?page=all ]

Meriah Garrett resolved JBFORUMS-229.
-------------------------------------

    Fix Version/s:     (was: 1.0.1 RC)
       Resolution: Done

> Redesign LnF for Moderator Panel
> --------------------------------
>
>                 Key: JBFORUMS-229
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-229
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum View Layer
>            Reporter: James Cobb
>         Assigned To: Meriah Garrett
>
> Redesign the page view based on the new forums look and feel. Look for usability wins in the process. 
> Whole moderator panel is not rethemed. 
> You need to log in as admin/admin: 
> http://forums.proto.jboss.com:8080/portal/auth/portal/default/Forum/Forums?action=1&v=m&f=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 lists.jboss.org  Tue Aug 28 17:22:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 17:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1650) Add descriptions
 and unify Theme pages
Message-ID: <22204306.1188336138482.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add descriptions and unify Theme pages
--------------------------------------

                 Key: JBPORTAL-1650
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1650
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 28 17:24:34 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 28 Aug 2007 17:24:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
Message-ID: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>

Duplicate FixMe Class Entries In jar Table of Contents
------------------------------------------------------

                 Key: JBPORTAL-1651
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final
            Reporter: Mike Millson
         Assigned To: Julien Viet
            Priority: Minor


Running the following command shows 2 FixMe.class entries in the table of contents.
jar tf portal-common-lib.jar | grep FixMe

Creating an index (jar i portal-common-lib.jar) results in the following exception:
java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class

This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:26:25 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 17:26:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1650) Add descriptions
 and unify Theme pages
In-Reply-To: <22204306.1188336138482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16509006.1188336385099.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1650?page=all ]

Chris Laprun updated JBPORTAL-1650:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final

> Add descriptions and unify Theme pages
> --------------------------------------
>
>                 Key: JBPORTAL-1650
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1650
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 17:26:25 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 28 Aug 2007 17:26:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20687125.1188336385755.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=all ]

Mike Millson updated JBPORTAL-1651:
-----------------------------------

    Attachment: patch.txt

Patch implementing duplicate="preserve" solution.

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Julien Viet
>            Priority: Minor
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:30:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 17:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27514694.1188336618472.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=all ]

Thomas Heute updated JBPORTAL-1651:
-----------------------------------

    Fix Version/s: 2.6.2 Final
         Assignee: Thomas Heute  (was: Julien Viet)

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:32:19 2007
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Tue, 28 Aug 2007 17:32:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1651) Duplicate
 FixMe Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2452086.1188336739544.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=comments#action_12374305 ] 
            
Mike Millson commented on JBPORTAL-1651:
----------------------------------------

The following version of this jar in repository.jboss.com also has the duplicate FixMe class in the table of contents:
http://repository.jboss.com/jboss-portal/modules/common/1.0.0-SNAPSHOT/lib/portal-common-lib.jar

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 17:37:23 2007
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Aug 2007 17:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4619) Add
 parseRoleNameFromDN option to LdapExtLoginModule
In-Reply-To: <30590688.1187717718399.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17888277.1188337043364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4619?page=all ]

Anil Saldhana closed JBAS-4619.
-------------------------------

    Resolution: Done

> Add parseRoleNameFromDN option to LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: JBAS-4619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4619
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
>            Reporter: Mike Millson
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.2.2.GA
>
>
> Provide an option to parse the role name out of the memberOf attributes, rather than re-query LDAP for each role. 
> The option would look something like:
> <module-option name="roleAttributeIsDN">true</module-option>
> <module-option name="roleNameAttributeID">myprofile</module-option>
> <module-option name="parseRoleNameFromDN">true</module-option>
> Alternatively, this could automatically be done if the memberOf attribute contained the roleNameAttributeID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:53:18 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Tue, 28 Aug 2007 17:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-387) Throw Exceptions when
 a valid advice is not found
In-Reply-To: <29000092.1176742620837.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7370692.1188337998857.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-387?page=all ]

Flavia Rainone closed JBAOP-387.
--------------------------------

    Resolution: Done

> Throw Exceptions when a valid advice is not found
> -------------------------------------------------
>
>                 Key: JBAOP-387
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-387
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Flavia Rainone
>         Assigned To: Flavia Rainone
>             Fix For: 2.0.0.beta
>
>
> We need to throw an exception warning the user that a valid advice method couldn't be found for a specific joinpoint scenario. (currently, we are printing warnings in the org.jboss.aop.advice.annotation.AdviceMethodFactory algorithm).
> This task involves changes to org.jboss.aop.advice.PerVMAdvice and org.jboss.aop.advice.annotation.AdviceMethodFactory classes.
> We also need to update the documentation, telling when this runtime exception will be thrown.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 17:55:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 17:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7809877.1188338118835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=all ]

Thomas Heute resolved JBPORTAL-1651.
------------------------------------

    Resolution: Done

Will be correct in 2.6.2, thank you Mike !

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 18:01:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Aug 2007 18:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4641) Move
 XMLJUnitMultipleResultFormatter from testsuite module to test module
In-Reply-To: <184925.1188321258850.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24518379.1188338478219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4641?page=all ]

Brian Stansberry closed JBAS-4641.
----------------------------------

    Resolution: Done

> Move XMLJUnitMultipleResultFormatter from testsuite module to test module
> -------------------------------------------------------------------------
>
>                 Key: JBAS-4641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.2.2.GA
>
>
> In Branch_4_2, this class is located in the testsuite module rather than in test.  In trunk it's in the jboss-test.jar, so logically it belongs in the test module in Branch_4_2.
> I need this class to get separate reports of the same EJB3 test under different configs (see EJBTHREE-856).  The EJB3 testsuite setup that tries to use the std ant XMLJUnitResultFormatter with different "extension" attribute values doesn't work.  I don't want to add the testsuite module to the junit task classpath in EJB3; that could have too many unintended side effects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 19:33:19 2007
From: jira-events at lists.jboss.org (Julien Viet (JIRA))
Date: Tue, 28 Aug 2007 19:33:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1651) Duplicate
 FixMe Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6212467.1188343999596.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=comments#action_12374324 ] 
            
Julien Viet commented on JBPORTAL-1651:
---------------------------------------

The generated jar in common is wrong it is missing some classes now and prevent other modules to be build or to link correctly. (like TransactionAssert)


> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 19:37:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 19:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-276) generate bpel
 application descriptor along with wsdl service description
In-Reply-To: <23516822.1187644158226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5203864.1188344238233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-276?page=all ]

Alejandro Guizar updated BPEL-276:
----------------------------------

    Description: 
PROBLEM The associations between the partner links and the published WSDL ports are declared in bpel-application.xml. 

In the provided examples, such associations can be inferred and are not present in the descriptor. This is because only one port in the WSDL document implements the port type associated with each partner link. In the general case, however, multiple ports may implement the same port type, making the association to partner links ambiguous.

During the procedure to generate a WSDL service description, the tool generates the WSDL port for each partner link and retains the unambiguous associations, but does not preserve them.

PROPOSAL Have the service description tool write the associations between partner links and WSDL ports to a generated bpel-application.xml file.

> generate bpel application descriptor along with wsdl service description
> ------------------------------------------------------------------------
>
>                 Key: BPEL-276
>                 URL: http://jira.jboss.com/jira/browse/BPEL-276
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The associations between the partner links and the published WSDL ports are declared in bpel-application.xml. 
> In the provided examples, such associations can be inferred and are not present in the descriptor. This is because only one port in the WSDL document implements the port type associated with each partner link. In the general case, however, multiple ports may implement the same port type, making the association to partner links ambiguous.
> During the procedure to generate a WSDL service description, the tool generates the WSDL port for each partner link and retains the unambiguous associations, but does not preserve them.
> PROPOSAL Have the service description tool write the associations between partner links and WSDL ports to a generated bpel-application.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 lists.jboss.org  Tue Aug 28 19:41:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1644) Add Default
 status / Make Default action to object (e.g. portal, page) tables
In-Reply-To: <4492260.1187722530673.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9351632.1188344478538.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1644?page=all ]

Chris Laprun resolved JBPORTAL-1644.
------------------------------------

    Resolution: Done

> Add Default status / Make Default action to object (e.g. portal, page) tables
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1644
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1644
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 19:45:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1650) Add
 descriptions and unify Theme pages
In-Reply-To: <22204306.1188336138482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4717266.1188344718220.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1650?page=all ]

Chris Laprun resolved JBPORTAL-1650.
------------------------------------

    Resolution: Done

> Add descriptions and unify Theme pages
> --------------------------------------
>
>                 Key: JBPORTAL-1650
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1650
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 19:51:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1652) Unify "create"
 button text in Create New * forms
Message-ID: <1889953.1188345078189.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unify "create" button text in Create New * forms
------------------------------------------------

                 Key: JBPORTAL-1652
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1652
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Tue Aug 28 19:53:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Tue, 28 Aug 2007 19:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1652) Unify "create"
 button text in Create New * forms
In-Reply-To: <1889953.1188345078189.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22395266.1188345198176.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1652?page=all ]

Chris Laprun updated JBPORTAL-1652:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final

> Unify "create" button text in Create New * forms
> ------------------------------------------------
>
>                 Key: JBPORTAL-1652
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1652
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Tue Aug 28 20:19:18 2007
From: jira-events at lists.jboss.org (William DeCoste (JIRA))
Date: Tue, 28 Aug 2007 20:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1033) Add EJB2.x JMX
 metrics to EJB3
In-Reply-To: <19347205.1187704052441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10284515.1188346758346.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1033?page=all ]

William DeCoste reassigned EJBTHREE-1033:
-----------------------------------------

    Assignee: William DeCoste  (was: Carlo de Wolf)

> Add EJB2.x JMX metrics to EJB3
> ------------------------------
>
>                 Key: EJBTHREE-1033
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1033
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>            Reporter: Carlo de Wolf
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC11 - FD
>
>
> Stateless: AvailableCount, MaxSize, CurrentSize, CreateCount, RemoveCount
> Stateful: CacheSize, PassivatedCount, CreateCount, RemoveCount, AvailableSize, CurrentSize, MaxSize
> MDB: MinPoolSize, MaxPoolSize, MaxMessages, KeepAliveMillis

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 21:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 21:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29496315.1188350658342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1026?page=all ]

Clebert Suconic reassigned JBMESSAGING-1026:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Ensure successfull test run against all supported databases
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Postgresql, MySQL, Sybase, Oracle, MSSQL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 21:24:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 21:24:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1048) Test DB2
 config against Hudson
In-Reply-To: <16680822.1187133001211.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28348628.1188350658546.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1048?page=comments#action_12374331 ] 
            
Clebert Suconic commented on JBMESSAGING-1048:
----------------------------------------------

Here is some useful doc
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0sttmsg.htm

> Test DB2 config against Hudson
> ------------------------------
>
>                 Key: JBMESSAGING-1048
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1048
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 2.0.0 Beta 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 lists.jboss.org  Tue Aug 28 21:31:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 28 Aug 2007 21:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1026) Ensure
 successfull test run against all supported databases
In-Reply-To: <18116833.1186597189485.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30057349.1188351078294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1026?page=all ]

Clebert Suconic closed JBMESSAGING-1026.
----------------------------------------

    Resolution: Done

> Ensure successfull test run against all supported databases
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1026
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1026
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Postgresql, MySQL, Sybase, Oracle, MSSQL

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Aug 28 22:51:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 22:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1651) Duplicate
 FixMe Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30538916.1188355878353.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=comments#action_12374334 ] 
            
Thomas Heute commented on JBPORTAL-1651:
----------------------------------------

Then there is a packaging issue:

I changed this:
	      <jar jarfile="${build.lib}/portal-common-lib.jar" manifest="${build.etc}/portal-common-lib-jar.mf">
                <fileset dir="${build.classes}"/>
	         <fileset dir="${build.resources}/format/code"/>
               <fileset dir="${build.classes}">
                <exclude name="org/jboss/portal/common/ant/**/*"/>
                <exclude name="org/jboss/portal/common/junit/**/*"/>
             </fileset>
	      </jar>

to this:
	      <jar jarfile="${build.lib}/portal-common-lib.jar" manifest="${build.etc}/portal-common-lib-jar.mf">
	         <fileset dir="${build.resources}/format/code"/>
             <fileset dir="${build.classes}">
                <exclude name="org/jboss/portal/common/ant/**/*"/>
                <exclude name="org/jboss/portal/common/junit/**/*"/>
             </fileset>
	      </jar>

ant and junit packages being in explode.jar.

I'll check on that

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 22:51:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 22:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20978742.1188355878492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=all ]

Thomas Heute reopened JBPORTAL-1651:
------------------------------------

             

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 22:53:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Tue, 28 Aug 2007 22:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1651) Duplicate FixMe
 Class Entries In jar Table of Contents
In-Reply-To: <11434569.1188336274846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1360855.1188355998328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1651?page=all ]

Thomas Heute resolved JBPORTAL-1651.
------------------------------------

    Resolution: Done

oups you fixed this already.

Thanks and sorry

> Duplicate FixMe Class Entries In jar Table of Contents
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1651
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1651
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Mike Millson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.6.2 Final
>
>         Attachments: patch.txt
>
>
> Running the following command shows 2 FixMe.class entries in the table of contents.
> jar tf portal-common-lib.jar | grep FixMe
> Creating an index (jar i portal-common-lib.jar) results in the following exception:
> java.util.zip.ZipException: duplicate entry: org/jboss/portal/common/FixMe.class
> This is caused by duplicate classes being specified for the jar task. One solution would be to set duplicate="preserve" on the ant jar task  that creates the 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 lists.jboss.org  Tue Aug 28 23:20:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Tue, 28 Aug 2007 23:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-276) generate bpel
 application descriptor along with wsdl service description
In-Reply-To: <23516822.1187644158226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22934969.1188357618209.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-276?page=all ]

Alejandro Guizar resolved BPEL-276.
-----------------------------------

    Resolution: Done

SOLUTION Modified the wsdl service generation tool to produce an application descriptor object. Introduced a descriptor writer that transforms the descriptor object into a DOM tree which is later saved as XML.

> generate bpel application descriptor along with wsdl service description
> ------------------------------------------------------------------------
>
>                 Key: BPEL-276
>                 URL: http://jira.jboss.com/jira/browse/BPEL-276
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 GA
>
>
> PROBLEM The associations between the partner links and the published WSDL ports are declared in bpel-application.xml. 
> In the provided examples, such associations can be inferred and are not present in the descriptor. This is because only one port in the WSDL document implements the port type associated with each partner link. In the general case, however, multiple ports may implement the same port type, making the association to partner links ambiguous.
> During the procedure to generate a WSDL service description, the tool generates the WSDL port for each partner link and retains the unambiguous associations, but does not preserve them.
> PROPOSAL Have the service description tool write the associations between partner links and WSDL ports to a generated bpel-application.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 lists.jboss.org  Wed Aug 29 03:13:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Wed, 29 Aug 2007 03:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-797)
 BisocketClientInvoker.PingTimerTask should terminate more gracefully
Message-ID: <5016115.1188371598220.JavaMail.jira@cloud.prod.atl2.jboss.com>

BisocketClientInvoker.PingTimerTask should terminate more gracefully
--------------------------------------------------------------------

                 Key: JBREM-797
                 URL: http://jira.jboss.com/jira/browse/JBREM-797
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.2.GA
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
            Priority: Minor
             Fix For: 2.4.0.Beta1 (Pinto)


If org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask is running when PingTimerTask.shutDown() is called, it might get an exception trying to send a ping.  However, there is no reason to log a warning.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 03:19:37 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 29 Aug 2007 03:19:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-584) Reconnection with TCP
 might not work well
Message-ID: <19639183.1188371977487.JavaMail.jira@cloud.prod.atl2.jboss.com>

Reconnection with TCP might not work well
-----------------------------------------

                 Key: JGRP-584
                 URL: http://jira.jboss.com/jira/browse/JGRP-584
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


If we use TCP, then a shun followed by an automatic reconnect may not work, as the reconnect will fail to join due to the reincarnation issue (http://jira.jboss.com/jira/browse/JGRP-130).
Investigate whether this works. If it doesn't work, we can possibly run the reconnect in a loop until the rejoin is successful, or until the channel is closed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 03:41:47 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Wed, 29 Aug 2007 03:41:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27475250.1188373307345.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=comments#action_12374367 ] 
            
Andrew Rubinger commented on EJBTHREE-1025:
-------------------------------------------

Tests merged to trunk in 64940, fix in 64941.

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Andrew Rubinger
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 04:48:25 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 04:48:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1564) Review Event
	chapter (IPC)
In-Reply-To: <30907420.1184080660159.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32728378.1188377305348.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1564?page=all ]

Thomas Heute resolved JBPORTAL-1564.
------------------------------------

    Resolution: Done

> Review Event chapter (IPC)
> --------------------------
>
>                 Key: JBPORTAL-1564
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1564
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> The event chapter is missing info about jboss-config.xml and -object to write.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 04:58:28 2007
From: jira-events at lists.jboss.org (Felipe Jensen Casado (JIRA))
Date: Wed, 29 Aug 2007 04:58:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23381026.1188377908951.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374374 ] 
            
Felipe Jensen Casado commented on BPEL-277:
-------------------------------------------

My process is 1.1 and you are totally right, Alejandro: It works perfectly, sorry. I had also tried using a qname, but my mistake was writing the name of the part in the query, instead of the name of the xsd element.

Thanks for the help and so this is closed.
Greetings.

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 05:09:37 2007
From: jira-events at lists.jboss.org (Felipe Jensen Casado (JIRA))
Date: Wed, 29 Aug 2007 05:09:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-277) message parts with
 the atribute element won't be accepted by bpel
In-Reply-To: <12904995.1188309858291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31005845.1188378577525.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-277?page=comments#action_12374375 ] 
            
Felipe Jensen Casado commented on BPEL-277:
-------------------------------------------

And thanks also for the specification of the representation of parts. I haven't found anything about it in the wsdl nor the bpel 1.1 specifications.

> message parts with the atribute element won't be accepted by bpel
> -----------------------------------------------------------------
>
>                 Key: BPEL-277
>                 URL: http://jira.jboss.com/jira/browse/BPEL-277
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 3
>         Environment: Running Java sdk 1.5.0_11, Jboss AS 4.0.5 GA and ant 1.7 in SunOs 5.9
>            Reporter: Felipe Jensen Casado
>         Assigned To: Alejandro Guizar
>
> Wsdl specification allows the use of the attribute element or type to refer to the XSD definition of the part (Cf. http://www.w3.org/TR/2001/NOTE-wsdl-20010315.html#_messages )
> However, when using the following definitions:
> <element name="EE">
>   <complexType>
>      <sequence>
>         <element name="usuario" type="xsd:string"/>
>         <element name="sistema" type="xsd:string"/>
>      </sequence>
>    </complexType>
> </element>
> <wsdl:message name="pruebaE">
>       <wsdl:part name="entrada" element="tns1:EE"/>
> </wsdl:message>
> <variable name="entradaPruebaE" messageType="BA:pruebaE"/>
>     
> <copy>
>       	<from variable="nombres" />
>       	<to variable="entradaPruebaElectrica" part="entrada" query="/entrada/usuario"/>
>  </copy>
> It will throw the following exception:
> 2007-08-28 14:45:28,291 DEBUG [org.jbpm.bpel.graph.scope.FaultActionHandler] handling fault: org.jbpm.bpel.gra
> ph.exe.ScopeInstance at 1f8ab0d[name=<null>,token=/,state=performingPrimaryActivity,id=0]
> org.jbpm.bpel.graph.exe.BpelFaultException: org.jbpm.bpel.graph.exe.FaultInstance at 4a1535[name={http://schemas.
> xmlsoap.org/ws/2004/03/business-process/}selectionFailure,id=0]
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.createNode(XPathEvaluator.java:100)
>         at org.jbpm.bpel.sublang.xpath.XPathEvaluator.selectOrCreateNodes(XPathEvaluator.java:79)
> In the addressed part of XPathEvaluator, the following can be read:
>   if (!(node instanceof Element)) {
>       // cannot create node for a non-element parent
>       throw new BpelFaultException(BpelConstants.FAULT_SELECTION_FAILURE);
>     }
> This won't happen when using a type especification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 05:21:27 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 05:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1580) [PATCH] updated
 helloworld jsf portlet
In-Reply-To: <8511276.1184442783989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <400809.1188379287519.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1580?page=all ]

Thomas Heute resolved JBPORTAL-1580.
------------------------------------

    Resolution: Done

> [PATCH] updated helloworld jsf portlet
> --------------------------------------
>
>                 Key: JBPORTAL-1580
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1580
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Samples
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: helloworldportlet.zip
>
>
> I also uploaded this to portalswap but I'm not sure it is being monitored.  This is an updated version of the helloworldjsf that works on JBP 2.6+JBAS 4.2.  The previous one that was there did NOT work on the 2.6/4.2 combo.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 06:21:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 29 Aug 2007 06:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4647) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.CR1
Message-ID: <8465370.1188382878491.JavaMail.jira@cloud.prod.atl2.jboss.com>

Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.CR1
--------------------------------------------------------------------

                 Key: JBAS-4647
                 URL: http://jira.jboss.com/jira/browse/JBAS-4647
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-5.0.0.CR1


Create subtasks to track jboss and thirdparty 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 lists.jboss.org  Wed Aug 29 06:21:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 29 Aug 2007 06:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4648) Upgrade jboss
 transactions to 4.4 (from 4.3)
Message-ID: <10620822.1188382878617.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss transactions to 4.4 (from 4.3)
--------------------------------------------

                 Key: JBAS-4648
                 URL: http://jira.jboss.com/jira/browse/JBAS-4648
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 06:23:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Wed, 29 Aug 2007 06:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4648) Upgrade jboss
 transactions to 4.4 (from 4.3)
In-Reply-To: <10620822.1188382878617.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31994488.1188382998387.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4648?page=all ]

Dimitris Andreadis reassigned JBAS-4648:
----------------------------------------

    Assignee: Jonathan Halliday

> Upgrade jboss transactions to 4.4 (from 4.3)
> --------------------------------------------
>
>                 Key: JBAS-4648
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4648
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Jonathan Halliday
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 06:34:18 2007
From: jira-events at lists.jboss.org (Michal Borowiecki (JIRA))
Date: Wed, 29 Aug 2007 06:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-91) AJP implementation
 broken :
 ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
Message-ID: <6742831.1188383658382.JavaMail.jira@cloud.prod.atl2.jboss.com>

AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
------------------------------------------------------------------------------------------------

                 Key: JBWEB-91
                 URL: http://jira.jboss.com/jira/browse/JBWEB-91
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Linux 2.6.20-gentoo-r8 #1 SMP
jbossweb-1.0.1.GA-linux2-i686.tar.gz
sun-jdk-1.5.0.11 and sun-jdk-1.6.0.01
Apache: Apache/1.3.37
JK: mod_jk/1.2.18
            Reporter: Michal Borowiecki
         Assigned To: Mladen Turk
             Fix For:  JBoss Web Server 1.0.1 GA


When response is greater than abount 225 kB and error is detected on Apache side in mod_jK:

last normal log entry:
[Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for

then error:
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed

At another time the error message said:
[Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
or
[Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c

JBoss logs show a normal response sent: 
[29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
[29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579

Apache logs show an error:
[29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
[29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265

The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 06:48:18 2007
From: jira-events at lists.jboss.org (Michal Borowiecki (JIRA))
Date: Wed, 29 Aug 2007 06:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-91) AJP implementation
 broken :
 ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
In-Reply-To: <6742831.1188383658382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14156851.1188384498262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-91?page=all ]

Michal Borowiecki updated JBWEB-91:
-----------------------------------

    Description: 
When response is greater than about 225 kB an error is detected on Apache side in mod_jK:

last normal log entry:
[Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for

then error:
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed

At another time the error message said:
[Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
or
[Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c

JBoss logs show a normal response sent: 
[29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
[29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579

Apache logs show an error:
[29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
[29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265

The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

  was:
When response is greater than abount 225 kB and error is detected on Apache side in mod_jK:

last normal log entry:
[Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for

then error:
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
[Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
[Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed

At another time the error message said:
[Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
or
[Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c

JBoss logs show a normal response sent: 
[29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
[29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579

Apache logs show an error:
[29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
[29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265

The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.


fixed typoos

> AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-91
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-91
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Linux 2.6.20-gentoo-r8 #1 SMP
> jbossweb-1.0.1.GA-linux2-i686.tar.gz
> sun-jdk-1.5.0.11 and sun-jdk-1.6.0.01
> Apache: Apache/1.3.37
> JK: mod_jk/1.2.18
>            Reporter: Michal Borowiecki
>         Assigned To: Mladen Turk
>             Fix For:  JBoss Web Server 1.0.1 GA
>
>
> When response is greater than about 225 kB an error is detected on Apache side in mod_jK:
> last normal log entry:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for
> then error:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed
> At another time the error message said:
> [Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
> or
> [Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c
> JBoss logs show a normal response sent: 
> [29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
> [29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579
> Apache logs show an error:
> [29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
> [29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265
> The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 07:03:18 2007
From: jira-events at lists.jboss.org (Michal Borowiecki (JIRA))
Date: Wed, 29 Aug 2007 07:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-91) AJP implementation
 broken :
 ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
In-Reply-To: <6742831.1188383658382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20267897.1188385398288.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-91?page=comments#action_12374382 ] 
            
Michal Borowiecki commented on JBWEB-91:
----------------------------------------

Serving the same JPS page/ static file works fine when using the HTTP connector.
The problem only affects the AJP connector.

> AJP implementation broken : ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-91
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-91
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Linux 2.6.20-gentoo-r8 #1 SMP
> jbossweb-1.0.1.GA-linux2-i686.tar.gz
> sun-jdk-1.5.0.11 and sun-jdk-1.6.0.01
> Apache: Apache/1.3.37
> JK: mod_jk/1.2.18
>            Reporter: Michal Borowiecki
>         Assigned To: Mladen Turk
>             Fix For:  JBoss Web Server 1.0.1 GA
>
>
> When response is greater than about 225 kB an error is detected on Apache side in mod_jK:
> last normal log entry:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1037): 03f0    75 6C 74 3D 64 6F 63 75 6D 65 6E 74 2E 66 6F 72  - ult=document.for
> then error:
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x743d from 192.168.0.34:8139
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_get_reply::jk_ajp_common.c (1556): Tomcat is down or network problems. Part of the response has already been sent to the client
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1751): Receiving from tomcat failed, recoverable operation attempt=1
> [Wed Aug 29 11:24:57 2007] [97923:0000] [info]  ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed,  recoverable operation attempt=2
> [Wed Aug 29 11:24:57 2007] [97923:0000] [error] ajp_service::jk_ajp_common.c (1794): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=server3 failed
> At another time the error message said:
> [Wed Aug 29 11:02:26 2007] [84055:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x2263
> or
> [Wed Aug 29 11:02:32 2007] [34375:0000] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (981): wrong message format 0x656c
> JBoss logs show a normal response sent: 
> [29/Aug/2007:11:02:24 +0200] "GET /is/transactions.jsf HTTP/1.1" 200 373004
> [29/Aug/2007:11:02:30 +0200] "POST /is/transactions.jsf HTTP/1.1" 200 372579
> Apache logs show an error:
> [29/Aug/2007:11:02:26 +0200] "GET /is/transactions.jsf HTTP/1.1" 503 265
> [29/Aug/2007:11:02:32 +0200] "POST /is/transactions.jsf HTTP/1.1" 503 265
> The same Apache/mod_jk configuration works fine talking to JBoss-4.0.5.GA so the bug must be jboss web server specific.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:22:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 09:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-856) Use Buddy
 Replication for clustered SFSBs
In-Reply-To: <24225310.1170195680226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22026767.1188393738856.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-856?page=all ]

Brian Stansberry updated EJBTHREE-856:
--------------------------------------

    Fix Version/s: AS 4.2.2.GA

> Use Buddy Replication for clustered SFSBs
> -----------------------------------------
>
>                 Key: EJBTHREE-856
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-856
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: EJB 3.0 RC11 - FD, AS 4.2.2.GA
>
>
> Optimize the replicated SFSB cache for use with Buddy Replication.  Basically means checking cache calls to ensure unwanted data gravitations do not 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 lists.jboss.org  Wed Aug 29 09:29:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 09:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4649) Upgrade to JBoss
	Cache 1.4.1.SP4
Message-ID: <6760331.1188394158264.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade to JBoss Cache 1.4.1.SP4
--------------------------------

                 Key: JBAS-4649
                 URL: http://jira.jboss.com/jira/browse/JBAS-4649
             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.2.2.GA


>From 1.4.1.SP3.  Needed for EJBTHREE-856.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:36:13 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 09:36:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4649) Upgrade to JBoss
	Cache 1.4.1.SP4
In-Reply-To: <6760331.1188394158264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19033459.1188394573078.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4649?page=all ]

Brian Stansberry closed JBAS-4649.
----------------------------------

    Resolution: Done

> Upgrade to JBoss Cache 1.4.1.SP4
> --------------------------------
>
>                 Key: JBAS-4649
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4649
>             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.2.2.GA
>
>
> From 1.4.1.SP3.  Needed for EJBTHREE-856.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:41:18 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Aug 2007 09:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4650)
 JSFIntegrationUnitTestCase is failing for JBoss AS 5
Message-ID: <20338587.1188394878196.JavaMail.jira@cloud.prod.atl2.jboss.com>

JSFIntegrationUnitTestCase is failing for JBoss AS 5
----------------------------------------------------

                 Key: JBAS-4650
                 URL: http://jira.jboss.com/jira/browse/JBAS-4650
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Stan Silvert
         Assigned To: Stan Silvert
             Fix For: JBossAS-5.0.0.GA


JSFIntegrationUnitTestCase fails.  The specific assertion that fails is in the logging test.  This was caused by setting a default logging level for JSF in log4j.xml.

If you run the test twice, it will pass the second time because the test sets logging levels by hitting the Log4JService via HTTP.  However, because the WAR for the test is deployed before the logging levels were changed, the WAR would be deployed with the old logging values.  So the fix is to change the test to set the logging levels before the WAR 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 lists.jboss.org  Wed Aug 29 09:43:18 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Aug 2007 09:43:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4650)
 JSFIntegrationUnitTestCase is failing for JBoss AS 5
In-Reply-To: <20338587.1188394878196.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28751627.1188394998214.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4650?page=all ]

Stan Silvert resolved JBAS-4650.
--------------------------------

    Resolution: Done

Fixed

> JSFIntegrationUnitTestCase is failing for JBoss AS 5
> ----------------------------------------------------
>
>                 Key: JBAS-4650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4650
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Stan Silvert
>         Assigned To: Stan Silvert
>             Fix For: JBossAS-5.0.0.GA
>
>
> JSFIntegrationUnitTestCase fails.  The specific assertion that fails is in the logging test.  This was caused by setting a default logging level for JSF in log4j.xml.
> If you run the test twice, it will pass the second time because the test sets logging levels by hitting the Log4JService via HTTP.  However, because the WAR for the test is deployed before the logging levels were changed, the WAR would be deployed with the old logging values.  So the fix is to change the test to set the logging levels before the WAR 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 lists.jboss.org  Wed Aug 29 09:50:18 2007
From: jira-events at lists.jboss.org (Andrew Oliver (JIRA))
Date: Wed, 29 Aug 2007 09:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1653) WSRP descriptor
	is invalid
Message-ID: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP descriptor is invalid
--------------------------

                 Key: JBPORTAL-1653
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
    Affects Versions: 2.6.1 Final, 2.6 Final
            Reporter: Andrew Oliver
         Assigned To: Julien Viet


ref guid has:

<!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
   "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
<?xml version="1.0" standalone="yes"?>
<deployments>
  <deployment>
    <wsrp-producer id="bea" expiration-cache="120">
      <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
      <registration-data>
        <property>
          <name>registration/consumerRole</name>
          <lang>en</lang>
          <value>public</value>
      </registration-data>
    </wsrp-producer>
  </deployment>
</deployments>

should read:
<?xml version="1.0"?>
<!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
   "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
<deployments>
  <deployment>
    <wsrp-producer id="bea" expiration-cache="120">
      <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
      <registration-data>
        <property>
          <name>registration/consumerRole</name>
          <lang>en</lang>
          <value>public</value>
        </property>
      </registration-data>
    </wsrp-producer>
  </deployment>
</deployments>

(the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 09:57:30 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 09:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1653) WSRP descriptor
	is invalid
In-Reply-To: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24981572.1188395850060.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1653?page=all ]

Thomas Heute updated JBPORTAL-1653:
-----------------------------------

    Fix Version/s: 2.6.2 Final
         Assignee: Chris Laprun  (was: Julien Viet)

> WSRP descriptor is invalid
> --------------------------
>
>                 Key: JBPORTAL-1653
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Andrew Oliver
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final
>
>
> ref guid has:
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <?xml version="1.0" standalone="yes"?>
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> should read:
> <?xml version="1.0"?>
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>         </property>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> (the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:05:18 2007
From: jira-events at lists.jboss.org (Terry McKee (JIRA))
Date: Wed, 29 Aug 2007 10:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31879806.1188396318873.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374400 ] 
            
Terry McKee commented on JBAS-4491:
-----------------------------------

I also ran into this issue when trying to start the default configuration for JBoss 5.0.0.Beta2 with JDK 6.0.02.  No apps were deployed.  The server starts up correctly when I switch the JDK to version 5.0.12.

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Wed Aug 29 10:09:19 2007
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Aug 2007 10:09:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4651) myfaces and
 commons-el should only be referenced by test suite
Message-ID: <29002583.1188396559360.JavaMail.jira@cloud.prod.atl2.jboss.com>

myfaces and commons-el should only be referenced by test suite
--------------------------------------------------------------

                 Key: JBAS-4651
                 URL: http://jira.jboss.com/jira/browse/JBAS-4651
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Stan Silvert
         Assigned To: Stan Silvert


The myfaces jar and the commons-el jar are only used by the test suite.  Right now they are referenced in build-thirdparty.xml in the full build.  We need to figure out if these jars can be referenced by the test suite 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 lists.jboss.org  Wed Aug 29 10:19:43 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Wed, 29 Aug 2007 10:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1025) @Local and
 @Remote on a bean class must have values
In-Reply-To: <2543807.1186060789285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29498077.1188397183376.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1025?page=all ]

Andrew Rubinger resolved EJBTHREE-1025.
---------------------------------------

    Resolution: Done

> @Local and @Remote on a bean class must have values
> ---------------------------------------------------
>
>                 Key: EJBTHREE-1025
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1025
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Carlo de Wolf
>         Assigned To: Andrew Rubinger
>             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD
>
>
> From the API doc:
> "When used on the bean class, declares the local business interface(s) for a session bean. When used on an interface, designates that interface as a local business interface. In this case, no value() is provided."
> Thus the following is an illegal construct:
> @Stateless
> @Local
> @Remote
> public class OrderServiceBean implements OrderService {...}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:47:19 2007
From: jira-events at lists.jboss.org (Andrew Oliver (JIRA))
Date: Wed, 29 Aug 2007 10:47:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1653) WSRP
	descriptor is invalid
In-Reply-To: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32592087.1188398839117.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1653?page=comments#action_12374408 ] 
            
Andrew Oliver commented on JBPORTAL-1653:
-----------------------------------------

check it over, jira munged the cut and paste

> WSRP descriptor is invalid
> --------------------------
>
>                 Key: JBPORTAL-1653
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Andrew Oliver
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final
>
>
> ref guid has:
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <?xml version="1.0" standalone="yes"?>
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> should read:
> <?xml version="1.0"?>
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>         </property>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> (the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:54:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 10:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-931) Have defect with
 JavaBeans as fact.
In-Reply-To: <12767206.1182161952049.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12296788.1188399258277.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-931?page=comments#action_12374412 ] 
            
Mark Proctor commented on JBRULES-931:
--------------------------------------

Try latest trunk and do read he discussions in the mailing list archive on this topic with other similar systems. The issue is often relate to the code generation framework marking classes and/or methods final, including equals and hashcode, which stops those classes working as expected in Drools.
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules

> Have defect with JavaBeans as fact.
> -----------------------------------
>
>                 Key: JBRULES-931
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-931
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.6
>         Environment: W-XP SP2
>            Reporter: Anthony Tran
>         Assigned To: Mark Proctor
>             Fix For: 3.0.6
>
>
> I use XMLBeans to generate and compile Java classes at runtime, then parse XML files to be objects of classess which has been compiled. Those objects are added into working memory as facts in my application. JBOSS Rule engine can recognize those facts, but can't bound. 
> Ex: 
> rule
>   when
>     p:ProductService(type == "monitor")
>     u:User(product == p)
>   then
>     .....
> end
> The LHS is never fired.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 10:56:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 10:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7242950.1188399378506.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

Mark Proctor updated JBRULES-1136:
----------------------------------

    Fix Version/s: 4.0.1

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 11:01:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 11:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1142) nested accessors
 on the lhs of
 the memberOf (or not memberOf) operator lead to an exception
In-Reply-To: <33222909.1188302555335.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14364584.1188399678677.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1142?page=all ]

Edson Tirelli closed JBRULES-1142.
----------------------------------

    Fix Version/s: 4.0.1
       Resolution: Duplicate Issue

http://jira.jboss.org/jira/browse/JBRULES-1089

> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception
> -------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-1142
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1142
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Windows XP, Java 1.5, Drools 4.0.0.GA
>            Reporter: andreas kinell
>         Assigned To: Mark Proctor
>             Fix For: 4.0.1
>
>   Original Estimate: 5 hours
>  Remaining Estimate: 5 hours
>
> nested accessors on the lhs of the memberOf (or not memberOf) operator lead to an exception:
> business logic (pseudocode):
> class Position {
>    private Instrument instrument;
> }
> class Instrument {
>    private Currency currency;
> }
> with getters and setters.
> rule:
> $collection : Collection()
> $position : Position(instrument.currency not memberOf $collection)
> exception:
> org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 1f99eea
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:212)
> 	at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:110)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:119)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.propagateAssertTuple(SingleTupleSinkAdapter.java:20)
> 	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:162)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:168)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> 	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:623)
> 	at test.RuleTest.testRuleEngine1(RuleTest.java:99)
> Caused by: java.lang.ClassCastException: test.Currency
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:36)
> 	at org.drools.rule.PredicateConstraint.isAllowedCachedLeft(PredicateConstraint.java:206)
> 	... 33 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 lists.jboss.org  Wed Aug 29 11:03:32 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 11:03:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1052) When running
 stress tests wrong log4j.xml is picked up
In-Reply-To: <10580807.1187882838240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16684303.1188399812419.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1052?page=all ]

Clebert Suconic closed JBMESSAGING-1052.
----------------------------------------

    Resolution: Done

Stress tests were picking the right one, but DEBUG became too verbose, so I'm setting thresholds to INFO

> When running stress tests wrong log4j.xml is picked up
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1052
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1052
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> When running stress tests, the log4j.xml from tests/etc, but the log4j.xml from tests/etc/stress isn't being used.
> This means stress tests are being run on trace logging, which is incorrect (makes them take ages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 11:05:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 11:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7045900.1188399918694.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1060?page=all ]

Clebert Suconic reopened JBMESSAGING-1060:
------------------------------------------

             

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Wed Aug 29 11:09:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 11:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1060) Oracle
 Persistence hits a driver bug on binding blobs
In-Reply-To: <14122899.1188334218293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7634891.1188400158271.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1060?page=all ]

Clebert Suconic closed JBMESSAGING-1060.
----------------------------------------

    Resolution: Done

> Oracle Persistence hits a driver bug on binding blobs
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1060
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1060
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.4.0.CR2
>
>
> PageReferences is using the statement called INSERT_MESSAGE_CONDITIONAL, what's hitting an implementation bug on the Oracle driver...
> We will work around the 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 lists.jboss.org  Wed Aug 29 11:51:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 11:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1600) inherit
 security constraint between portal Template and dashboards
In-Reply-To: <17178120.1184859228977.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28348776.1188402678678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1600?page=all ]

Thomas Heute resolved JBPORTAL-1600.
------------------------------------

    Resolution: Done

The way it is done is that only viewable objects are copied now. It should solve your use-case

> inherit security constraint between portal Template and dashboards
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1600
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1600
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Lionel ROSIER
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> we can apply security settings on the template portal, particularly  on the pages.
> but the security constraints are not inherit from the portal Template to the dashboards.
> a page which is secured with a role in the portal template is visible by every users in their dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 11:53:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Aug 2007 11:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1600) Dashboard also
 includes protected resources from 'template' on creation
In-Reply-To: <17178120.1184859228977.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10662037.1188402798262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1600?page=all ]

Thomas Heute updated JBPORTAL-1600:
-----------------------------------

    Summary: Dashboard also includes protected resources from 'template' on creation  (was: inherit security constraint between portal Template and dashboards)

Thanks for the report !

> Dashboard also includes protected resources from 'template' on creation
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1600
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1600
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Lionel ROSIER
>         Assigned To: Thomas Heute
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> we can apply security settings on the template portal, particularly  on the pages.
> but the security constraints are not inherit from the portal Template to the dashboards.
> a page which is secured with a role in the portal template is visible by every users in their dashboard.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 12:13:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 12:13:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1061) Failure on
 ClusteredPostOfficeTest
Message-ID: <23025559.1188403999391.JavaMail.jira@cloud.prod.atl2.jboss.com>

Failure on ClusteredPostOfficeTest
----------------------------------

                 Key: JBMESSAGING-1061
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1061
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR2
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.CR2


Vladmir Blagojevic provided me this input about the ClusteredPostOfficeTest failures (related to the JGropus usage):

I have a workaround for you. I will continue to look for 100% solution in the coming days. What you have to do is introduce Thread.sleep(1000); at the end of GroupMember#stop() method. This gives a change to channels to cleanup properly. We get those errors from previous email when we rapidly shutdown bunch of channels.

After this change, specific test passes 100% and I get five failures and one error for the entire test. I get a lot of these:
  [junit] @main 10:20:48,203 WARN  [ProxyAssertSupport] AssertionFailure::junit.framework.AssertionFailedError
  [junit] junit.framework.AssertionFailedError
  [junit]     at junit.framework.Assert.fail(Assert.java:47)
  [junit]     at junit.framework.Assert.assertTrue(Assert.java:20)
  [junit]     at junit.framework.Assert.assertTrue(Assert.java:27)
  [junit]     at org.jboss.test.messaging.util.ProxyAssertSupport.assertTrue(ProxyAssertSupport.java:61)
  [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.clusteredRouteFourNodes(ClusteredPostOfficeTest.java:2140)
  [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.testClusteredRouteFourNodesNonPersistent(ClusteredPostOfficeTest.java:1374)
  [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  [junit]     at java.lang.reflect.Method.invoke(Method.java:585)
  [junit]     at junit.framework.TestCase.runTest(TestCase.java:164)
  [junit]     at junit.framework.TestCase.runBare(TestCase.java:130)
  [junit]     at junit.framework.TestResult$1.protect(TestResult.java:106)
  [junit]     at junit.framework.TestResult.runProtected(TestResult.java:124)
  [junit]     at junit.framework.TestResult.run(TestResult.java:109)
  [junit]     at junit.framework.TestCase.run(TestCase.java:120)
  [junit]     at junit.framework.TestSuite.runTest(TestSuite.java:230)
  [junit]     at junit.framework.TestSuite.run(TestSuite.java:225)
  [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
  [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
  [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)


but these seem to be related to message references. I tried changing these tests to use equals method rather than == and they started passing.
Not sure what are these about. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 12:15:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 12:15:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1061) Failure on
 ClusteredPostOfficeTest
In-Reply-To: <23025559.1188403999391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26146099.1188404119735.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1061?page=all ]

Clebert Suconic closed JBMESSAGING-1061.
----------------------------------------

    Resolution: Done

> Failure on ClusteredPostOfficeTest
> ----------------------------------
>
>                 Key: JBMESSAGING-1061
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1061
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>
> Vladmir Blagojevic provided me this input about the ClusteredPostOfficeTest failures (related to the JGropus usage):
> I have a workaround for you. I will continue to look for 100% solution in the coming days. What you have to do is introduce Thread.sleep(1000); at the end of GroupMember#stop() method. This gives a change to channels to cleanup properly. We get those errors from previous email when we rapidly shutdown bunch of channels.
> After this change, specific test passes 100% and I get five failures and one error for the entire test. I get a lot of these:
>   [junit] @main 10:20:48,203 WARN  [ProxyAssertSupport] AssertionFailure::junit.framework.AssertionFailedError
>   [junit] junit.framework.AssertionFailedError
>   [junit]     at junit.framework.Assert.fail(Assert.java:47)
>   [junit]     at junit.framework.Assert.assertTrue(Assert.java:20)
>   [junit]     at junit.framework.Assert.assertTrue(Assert.java:27)
>   [junit]     at org.jboss.test.messaging.util.ProxyAssertSupport.assertTrue(ProxyAssertSupport.java:61)
>   [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.clusteredRouteFourNodes(ClusteredPostOfficeTest.java:2140)
>   [junit]     at org.jboss.test.messaging.core.postoffice.ClusteredPostOfficeTest.testClusteredRouteFourNodesNonPersistent(ClusteredPostOfficeTest.java:1374)
>   [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   [junit]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   [junit]     at java.lang.reflect.Method.invoke(Method.java:585)
>   [junit]     at junit.framework.TestCase.runTest(TestCase.java:164)
>   [junit]     at junit.framework.TestCase.runBare(TestCase.java:130)
>   [junit]     at junit.framework.TestResult$1.protect(TestResult.java:106)
>   [junit]     at junit.framework.TestResult.runProtected(TestResult.java:124)
>   [junit]     at junit.framework.TestResult.run(TestResult.java:109)
>   [junit]     at junit.framework.TestCase.run(TestCase.java:120)
>   [junit]     at junit.framework.TestSuite.runTest(TestSuite.java:230)
>   [junit]     at junit.framework.TestSuite.run(TestSuite.java:225)
>   [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
>   [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
>   [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)
> but these seem to be related to message references. I tried changing these tests to use equals method rather than == and they started passing.
> Not sure what are these about. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 12:50:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 12:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1013) Run clustered
 session tests with buddy replication enabled and disabled
In-Reply-To: <14148841.1184355843699.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30583606.1188406218386.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1013?page=all ]

Brian Stansberry closed EJBTHREE-1013.
--------------------------------------

    Fix Version/s: AS 4.2.2.GA
       Resolution: Done

> Run clustered session tests with buddy replication enabled and disabled
> -----------------------------------------------------------------------
>
>                 Key: EJBTHREE-1013
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1013
>             Project: EJB 3.0
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD
>
>
> For trunk, enabled will be the default, so need to setup tests to run with BR 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 lists.jboss.org  Wed Aug 29 12:58:18 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Wed, 29 Aug 2007 12:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2603318.1188406698323.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374436 ] 
            
Remy Maucherat commented on JBAS-4562:
--------------------------------------

Ideally, I would like to integrate a CR release of JBoss Web 2.1 in the beta 3 build. This should not be an issue, but there will be a small update needed since this new version slightly updates the annotation integration interface. Would this be acceptable, or would you prefer sticking with a JBoss Web 2.0.1 GA and upgrading post beta 3  ?

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 13:26:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 13:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1653) WSRP descriptor
	is invalid
In-Reply-To: <29189277.1188395418415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20752555.1188408378297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1653?page=all ]

Chris Laprun resolved JBPORTAL-1653.
------------------------------------

    Fix Version/s: 2.8 Final
       Resolution: Done

> WSRP descriptor is invalid
> --------------------------
>
>                 Key: JBPORTAL-1653
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1653
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Reference Guide
>    Affects Versions: 2.6 Final, 2.6.1 Final
>            Reporter: Andrew Oliver
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> ref guid has:
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <?xml version="1.0" standalone="yes"?>
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> should read:
> <?xml version="1.0"?>
> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
>    "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
> <deployments>
>   <deployment>
>     <wsrp-producer id="bea" expiration-cache="120">
>       <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
>       <registration-data>
>         <property>
>           <name>registration/consumerRole</name>
>           <lang>en</lang>
>           <value>public</value>
>         </property>
>       </registration-data>
>     </wsrp-producer>
>   </deployment>
> </deployments>
> (the XML directive was on the wrong line, portal deployer balks at "standalone" and property tag not closed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 14:03:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1652) Unify "create"
 button text in Create New * forms
In-Reply-To: <1889953.1188345078189.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10618754.1188410598407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1652?page=all ]

Chris Laprun resolved JBPORTAL-1652.
------------------------------------

    Resolution: Done

> Unify "create" button text in Create New * forms
> ------------------------------------------------
>
>                 Key: JBPORTAL-1652
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1652
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Wed Aug 29 14:07:19 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:07:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1654) Add separators
 on object
 pages to allow for better distinction between object and children
 operations
Message-ID: <20695198.1188410839568.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add separators on object pages to allow for better distinction between object and children operations
-----------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1654
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1654
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Wed Aug 29 14:11:32 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:11:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1655) Improve "rename"
	forms
Message-ID: <2649337.1188411092173.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve "rename" forms
----------------------

                 Key: JBPORTAL-1655
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1655
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Wed Aug 29 14:13:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1656) NPE when trying
 to delete an
 object in the admin portlet and cancelling the operation by pressing No in
 the confirmation dialog
Message-ID: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
-------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1656
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.2 Final, 2.8 Final


java.lang.NullPointerException
	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 14:15:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 14:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1657) Improve confirm
 deletion pages
Message-ID: <30785252.1188411318174.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improve confirm deletion pages
------------------------------

                 Key: JBPORTAL-1657
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1657
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Wed Aug 29 14:33:29 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 14:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29504361.1188412409734.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=comments#action_12374456 ] 
            
Edson Tirelli commented on JBRULES-1131:
----------------------------------------

Added a getErrorLines() method to all DroolsError classes... need to integrate that into the engine and maybe do some improvements, as required.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Wed Aug 29 14:58:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 14:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1131) Errors not
 including line numbers
In-Reply-To: <27960474.1188060618354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19994790.1188413898311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1131?page=all ]

Edson Tirelli closed JBRULES-1131.
----------------------------------

    Resolution: Done

Fixed.

> Errors not including line numbers
> ---------------------------------
>
>                 Key: JBRULES-1131
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1131
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE, Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> I have an obvious error and its not showing line numbers, but does appear in the Errors output in the problems 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 lists.jboss.org  Wed Aug 29 16:55:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-8) Handling of (state)
 merging --> emission of callbacks/notifications
Message-ID: <13542193.1188420918746.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-8?page=all ]

Brian Stansberry updated JBCACHE-8:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

Added link to forum post.  I'm now doubting this is doable for 2.1. :(

> Handling of (state) merging --> emission of callbacks/notifications
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-8
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-8
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2.4SP1, 1.2.4, 1.2.4beta, 1.2.3, 1.2.2, 1.2.1, 1.2, 1.3.0.SP2, 1.3.0.SP1, 1.3.0.GA
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We need to look into handling the merge for JBossCache. Merging occurs after a network partition, or as result of 2 members starting concurrently, or as a result of a PING.timeout set too low

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:57:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4224) Handle merging of
 distributed session state if a MergeView is received
In-Reply-To: <23411494.1174424269688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6940985.1188421038300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4224?page=all ]

Brian Stansberry updated JBAS-4224:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handle merging of distributed session state if a MergeView is received
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4224
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4224
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs.  Need to work with the JBC team to design the callback and to implement a solution that will allow merging of web sessions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:57:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4223) Handle merging of
 ClusterPartition state if MergeView is received
In-Reply-To: <16889233.1174424148883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31477813.1188421038417.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4223?page=all ]

Brian Stansberry updated JBAS-4223:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handle merging of ClusterPartition state if MergeView is received
> -----------------------------------------------------------------
>
>                 Key: JBAS-4223
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4223
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 16:59:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-922) Handle merging of
 clustered SFSB state if a MergeView is received
In-Reply-To: <9987023.1174424388661.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30066962.1188421158629.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-922?page=all ]

Brian Stansberry updated EJBTHREE-922:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handle merging of clustered SFSB state if a MergeView is received
> -----------------------------------------------------------------
>
>                 Key: EJBTHREE-922
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-922
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs. Need to work with the JBC team to design the callback and to implement a solution that will allow merging of clustered SFSB 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 lists.jboss.org  Wed Aug 29 16:59:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-78) Handling of merge
Message-ID: <23531795.1188421158842.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-78?page=all ]

Brian Stansberry updated JBCLUSTER-78:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155

> Handling of merge
> -----------------
>
>                 Key: JBCLUSTER-78
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-78
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Brian Stansberry
>             Fix For: Q3Y7
>
>
> All building blocks which involve state do *not* implement handling of merging. E.g. DRM.mergeMembers() should invoke a callback so that each subscribed listener can handle the merge.
> This needs to be done for the existing building blocks for backward compatibility, the new mechanism used is JBossCache (see link) which will handle state merging

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-78) Handling of merge
Message-ID: <29512444.1188421159027.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-78?page=all ]

Brian Stansberry updated JBCLUSTER-78:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handling of merge
> -----------------
>
>                 Key: JBCLUSTER-78
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-78
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Brian Stansberry
>             Fix For: Q3Y7
>
>
> All building blocks which involve state do *not* implement handling of merging. E.g. DRM.mergeMembers() should invoke a callback so that each subscribed listener can handle the merge.
> This needs to be done for the existing building blocks for backward compatibility, the new mechanism used is JBossCache (see link) which will handle state merging

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4223) Handle merging of
 ClusterPartition state if MergeView is received
In-Reply-To: <16889233.1174424148883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28518241.1188421159166.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4223?page=all ]

Brian Stansberry updated JBAS-4223:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handle merging of ClusterPartition state if MergeView is received
> -----------------------------------------------------------------
>
>                 Key: JBAS-4223
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4223
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4224) Handle merging of
 distributed session state if a MergeView is received
In-Reply-To: <23411494.1174424269688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12951376.1188421159311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4224?page=all ]

Brian Stansberry updated JBAS-4224:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handle merging of distributed session state if a MergeView is received
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4224
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4224
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.Beta1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs.  Need to work with the JBC team to design the callback and to implement a solution that will allow merging of web sessions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 16:59:19 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 16:59:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-922) Handle merging of
 clustered SFSB state if a MergeView is received
In-Reply-To: <9987023.1174424388661.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2761984.1188421159480.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-922?page=all ]

Brian Stansberry updated EJBTHREE-922:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handle merging of clustered SFSB state if a MergeView is received
> -----------------------------------------------------------------
>
>                 Key: EJBTHREE-922
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-922
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: AS 4.2.0 GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>
> The JBCACHE-8 solution will provide a notification of when a cluster merge occurs. Need to work with the JBC team to design the callback and to implement a solution that will allow merging of clustered SFSB 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 lists.jboss.org  Wed Aug 29 17:01:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 29 Aug 2007 17:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-8) Handling of (state)
 merging --> emission of callbacks/notifications
Message-ID: <19434115.1188421278381.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-8?page=all ]

Brian Stansberry updated JBCACHE-8:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117402  (was: http://www.jboss.com/index.html?module=bb&op=viewforum&f=155)

> Handling of (state) merging --> emission of callbacks/notifications
> -------------------------------------------------------------------
>
>                 Key: JBCACHE-8
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-8
>             Project: JBoss Cache
>          Issue Type: Feature Request
>    Affects Versions: 1.2.4SP1, 1.2.4, 1.2.4beta, 1.2.3, 1.2.2, 1.2.1, 1.2, 1.3.0.SP2, 1.3.0.SP1, 1.3.0.GA
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We need to look into handling the merge for JBossCache. Merging occurs after a network partition, or as result of 2 members starting concurrently, or as a result of a PING.timeout set too low

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 17:11:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 17:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1656) NPE when
 trying to delete
 an object in the admin portlet and cancelling the operation by pressing No
 in the confirmation dialog
In-Reply-To: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16075175.1188421878331.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1656?page=comments#action_12374480 ] 
            
Chris Laprun commented on JBPORTAL-1656:
----------------------------------------

Only happens when trying to delete a window

> NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1656
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> java.lang.NullPointerException
> 	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 17:11:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 17:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1656) NPE when
 trying to delete
 an object in the admin portlet and cancelling the operation by pressing No
 in the confirmation dialog
In-Reply-To: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24682070.1188421878461.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1656?page=comments#action_12374481 ] 
            
Chris Laprun commented on JBPORTAL-1656:
----------------------------------------

and the portlet associated with the window is not deployed...

> NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1656
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> java.lang.NullPointerException
> 	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 17:26:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 29 Aug 2007 17:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1136) Rule not firing
 when expression contains nested accessors
In-Reply-To: <32024958.1188151338261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16340695.1188422778278.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1136?page=all ]

Edson Tirelli closed JBRULES-1136.
----------------------------------

    Resolution: Done

Fixed.

Thanks for reporting and providing test case.

> Rule not firing when expression contains nested accessors
> ---------------------------------------------------------
>
>                 Key: JBRULES-1136
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1136
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  4.0.0.GA
>         Environment: Wintel XP Pro SP2
>            Reporter: Sergey Manukyan
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>         Attachments: action_rules.drl, action_rules.drl, RuleBaseFacade.java, TestBug.java, TestBusinessStatus.java, TestSupplier.java
>
>
> Rule that use nested accessors in expressions don't fire. Although simple accessors fire just fine:
> For example :
> when exists( TestSupplier( testBusinessStatus.active == true ) )    -> NEVER FIRES
> when exists( TestSupplier( name == "TEST SUPPLIER" ) )   -> FIRES JUST FINE
> I am using StatefulSession.  Will attach the unit test to reproduce the problem.
> Just found same issue happens in other construct like collect :
> when ArrayList(size > 0) from collect(TestSupplier(testBusinessStatus.active == true))  ->NEVER FIRES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 20:19:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 20:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1657) Improve confirm
 deletion pages
In-Reply-To: <30785252.1188411318174.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21003789.1188433158328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1657?page=all ]

Chris Laprun resolved JBPORTAL-1657.
------------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final
       Resolution: Done

> Improve confirm deletion pages
> ------------------------------
>
>                 Key: JBPORTAL-1657
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1657
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Wed Aug 29 20:21:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Wed, 29 Aug 2007 20:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1656) NPE when trying
 to delete an
 object in the admin portlet and cancelling the operation by pressing No in
 the confirmation dialog
In-Reply-To: <16178258.1188411198529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18161147.1188433278261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1656?page=all ]

Chris Laprun resolved JBPORTAL-1656.
------------------------------------

    Resolution: Done

> NPE when trying to delete an object in the admin portlet and cancelling the operation by pressing No in the confirmation dialog
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1656
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1656
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> java.lang.NullPointerException
> 	at org.jboss.portal.core.admin.ui.PortalObjectManagerBean.getSelectedContentEditorInstance(PortalObjectManagerBean.java:198)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 20:56:24 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 20:56:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1144) Toggling
 breakpoint gives an exception
Message-ID: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>

Toggling breakpoint gives an exception
--------------------------------------

                 Key: JBRULES-1144
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1


Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 20:58:30 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 20:58:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4883883.1188435510547.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=all ]

Mark Proctor updated JBRULES-1144:
----------------------------------

    Attachment: screenshot-1.jpg

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:01:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 21:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1145) Break points do
 not work at all
Message-ID: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Break points do not work at all
-------------------------------

                 Key: JBRULES-1145
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1


Break points do not work 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 lists.jboss.org  Wed Aug 29 21:19:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 21:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1043) Make sure
 all examples work out of distro
In-Reply-To: <3531415.1186684741123.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29573193.1188436758315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1043?page=all ]

Clebert Suconic reassigned JBMESSAGING-1043:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> Make sure all examples work out of distro
> -----------------------------------------
>
>                 Key: JBMESSAGING-1043
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1043
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:19:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Aug 2007 21:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1043) Make sure all
 examples work out of distro
In-Reply-To: <3531415.1186684741123.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28094086.1188436758522.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1043?page=all ]

Clebert Suconic closed JBMESSAGING-1043.
----------------------------------------

    Resolution: Done

> Make sure all examples work out of distro
> -----------------------------------------
>
>                 Key: JBMESSAGING-1043
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1043
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.CR2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:47:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 21:47:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27515675.1188438438346.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=comments#action_12374513 ] 
            
Mark Proctor commented on JBRULES-1144:
---------------------------------------

Here is the stack trace:
org.drools.compiler.PackageBuilder$MissingPackageNameException: Missing package name for rule package.
at org.drools.compiler.PackageBuilder.validatePackageName(PackageBuilder.java:300)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:227)
at org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(Unknown Source)
at org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(Unknown Source)
at org.drools.eclipse.DroolsEclipsePlugin.parseResource(Unknown Source)
at org.drools.eclipse.debug.core.DroolsLineBreakpoint.setJavaBreakpointProperties(Unknown Source)
at org.drools.eclipse.debug.core.DroolsDebugTarget.breakpointAdded(Unknown Source)
at org.drools.eclipse.launching.DroolsLaunchConfigurationDelegate.launch(Unknown Source)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:639)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:565)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:754)
at org.eclipse.debug.internal.ui.DebugUIPlugin$6.run(DebugUIPlugin.java:944)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 21:58:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 21:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10494699.1188439098317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=all ]

Mark Proctor updated JBRULES-1144:
----------------------------------

    Attachment: screenshot-2.jpg

I did a project refresh and clean, and it looks like something deeper has gone wrong. Not a simple DRL will compile. Al with the same error.

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:16:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27128211.1188440178335.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=comments#action_12374523 ] 
            
Mark Proctor commented on JBRULES-1144:
---------------------------------------

I managed to fix this. I nucked my .metadata in eclipse and also deleted the project and re-checked it out. the errors did not re-appear. So we can probably close this off and put it down to an eclipse quirk.

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:26:38 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:26:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27140257.1188440798499.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374527 ] 
            
Mark Proctor commented on JBRULES-1145:
---------------------------------------

After nuking my .metadata it now stops at the break points, but it's still not working correctly. In the HelloWorld example in trunk, where there are two mvel rules. I put break points in both, in the first rule I can step through each line except the last. In the other rule it stops, but I can't step through at all, it just returns.

I think there is some dodgy caching going on. Initially the second rule only had two lines, so it couldn't step-over anyway, based on the bug above. I added some more lines and I still can't step-over them. I moved the location of the break point and it still stops at the old location.... very weird.

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>
> Break points do not work 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 lists.jboss.org  Wed Aug 29 22:28:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2459788.1188440898300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=all ]

Mark Proctor updated JBRULES-1145:
----------------------------------

    Attachment: screenshot-1.jpg

Here you can see it breaking, but there is no break point on this line.

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Wed Aug 29 22:33:18 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1146) No variables are
 shown for Debug points
Message-ID: <25789503.1188441198879.JavaMail.jira@cloud.prod.atl2.jboss.com>

No variables are shown for Debug points
---------------------------------------

                 Key: JBRULES-1146
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1146
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Ahti Kitsik
             Fix For: 4.0.1
         Attachments: screenshot-1.jpg

No variables are showing for break points.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:33:19 2007
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 29 Aug 2007 22:33:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1146) No variables are
 shown for Debug points
In-Reply-To: <25789503.1188441198879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18935340.1188441199059.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1146?page=all ]

Mark Proctor updated JBRULES-1146:
----------------------------------

    Attachment: screenshot-1.jpg

notice in the screen shot there is no variable information

> No variables are shown for Debug points
> ---------------------------------------
>
>                 Key: JBRULES-1146
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1146
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> No variables are showing for break points.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Aug 29 22:39:18 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Wed, 29 Aug 2007 22:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1040) add flag to
 improve
 deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
In-Reply-To: <18074307.1187995038327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33466870.1188441558553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1040?page=all ]

Andrew Rubinger reassigned EJBTHREE-1040:
-----------------------------------------

    Assignee: Andrew Rubinger  (was: William DeCoste)

> add flag to improve deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1040
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1040
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Andrew Rubinger
>            Priority: Minor
>
> Currently all jar/ejb3 files are scanned for the existence of annotated classes. This can cause slow deployment times. Create a switch with flag for only deploying jar/ejb3 files with either/or a ejb-jar.xml or jboss.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 lists.jboss.org  Thu Aug 30 02:22:18 2007
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Thu, 30 Aug 2007 02:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1040) add flag to
 improve
 deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
In-Reply-To: <18074307.1187995038327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15943043.1188454938464.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1040?page=all ]

Andrew Rubinger updated EJBTHREE-1040:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=117427

> add flag to improve deployment time by ignoring .jars/.ejb3 with no ejb-jar.xml or jboss.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1040
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1040
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: AS 4.2.1.GA
>            Reporter: William DeCoste
>         Assigned To: Andrew Rubinger
>            Priority: Minor
>
> Currently all jar/ejb3 files are scanned for the existence of annotated classes. This can cause slow deployment times. Create a switch with flag for only deploying jar/ejb3 files with either/or a ejb-jar.xml or jboss.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 lists.jboss.org  Thu Aug 30 03:39:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 03:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30979181.1188459558714.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374550 ] 
            
Dimitris Andreadis commented on JBAS-4562:
------------------------------------------

Remy, if the target for AS 5 is including JBoss Web 2.1.x, then upgrading to it as soon as possible is probably better, to reveal early on possible integration issues.

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 03:45:29 2007
From: jira-events at lists.jboss.org (Jannis Elgner (JIRA))
Date: Thu, 30 Aug 2007 03:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1604) Window state
 required but has no effect
In-Reply-To: <17779748.1184893247122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1970930.1188459929378.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1604?page=comments#action_12374551 ] 
            
Jannis Elgner commented on JBPORTAL-1604:
-----------------------------------------

You can change the windowstate with 

context.getPortalRuntimeContext().getNavigationalStateContext().setWindowState(windowA, WindowState.MINIMIZED); 

and the WindowMode with

context.getPortalRuntimeContext().getNavigationalStateContext().setMode(arg0, arg1);

instead ...

> Window state required but has no effect
> ---------------------------------------
>
>                 Key: JBPORTAL-1604
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1604
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Andrew Oliver
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 Final
>
>
> In 2.6 you must do this
>                newEvent.setMode(wae.getMode());
>                newEvent.setWindowState(org.jboss.portal.WindowState.MAXIMIZED);
>                newEvent.setParameters(wae.getParameters());
> when sending an event or you get an error.  However, the window state is completely ignored (the window would not be maximized with the above).  If it is required it should have some effect -- otherwise the api should revert to before where it was not 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 lists.jboss.org  Thu Aug 30 04:55:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMICROCONT-196) Need an api for
 deployment/component scopes in the deployers
In-Reply-To: <28243816.1184950787176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14821462.1188464118523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-196?page=all ]

Adrian Brock updated JBMICROCONT-196:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079481#4079481

> Need an api for deployment/component scopes in the deployers
> ------------------------------------------------------------
>
>                 Key: JBMICROCONT-196
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-196
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Need to define an api for deployer scopes for jsr77
> and the metadata repository scoping.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 04:55:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-196) Need an api for
 deployment/component scopes in the deployers
In-Reply-To: <28243816.1184950787176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23993348.1188464118703.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-196?page=all ]

Adrian Brock closed JBMICROCONT-196.
------------------------------------

    Resolution: Done

This has been done, see the forum thread.

> Need an api for deployment/component scopes in the deployers
> ------------------------------------------------------------
>
>                 Key: JBMICROCONT-196
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-196
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Need to define an api for deployer scopes for jsr77
> and the metadata repository scoping.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 04:57:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-31) ClassLoading
	abstraction
Message-ID: <6322750.1188464238649.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-31?page=all ]

Adrian Brock closed JBMICROCONT-31.
-----------------------------------

    Resolution: Done

This has been done in the jboss-integration project,
see org.jboss.classloading

> ClassLoading abstraction
> ------------------------
>
>                 Key: JBMICROCONT-31
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-31
>             Project: JBoss MicroContainer
>          Issue Type: Sub-task
>          Components: General
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Need to come up with a classloading abstraction that isn't going to change in future.
> e.g. Look at jboss-aop problem with
> 3.2.x UnifiedClassLoader
> 4.0.x RepositoryClassLoader
> 5.0.x ??? (not even JMX based)
> I think the easiest way to do this to define some simple interfaces/factories
> for where this needs to be referenced 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 lists.jboss.org  Thu Aug 30 04:57:19 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 04:57:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-182) Integrate VFS
 ClassLoader into new deployers and jboss-head
In-Reply-To: <28277006.1183399684364.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33109232.1188464239010.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-182?page=all ]

Adrian Brock closed JBMICROCONT-182.
------------------------------------

    Resolution: Done

This has been done, but the full OSGi classloading rules have not been implemented yet,
see the related task.

> Integrate VFS ClassLoader into new deployers and jboss-head
> -----------------------------------------------------------
>
>                 Key: JBMICROCONT-182
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-182
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: Deployment
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossMC-2.0.0.Beta4
>
>
> Integrate VFSClassLoader into JBoss Head, including OSGi dependencies/versioning

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 05:11:21 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 30 Aug 2007 05:11:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <173720.1188465081983.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374558 ] 
            
Ahti Kitsik commented on JBRULES-1145:
--------------------------------------

Confirming that using drools rev14749 I get:
* Last line breakpoint is not triggered. neither for breakpoint or stepover. if the last line is commented out then even line before that is not suspended.
* no variables visible anymore

Both features worked differently/OK yesterday when mvel trunk was used.

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 05:15:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 30 Aug 2007 05:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <881445.1188465318424.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374559 ] 
            
Michael Neale commented on JBRULES-1145:
----------------------------------------

yes and there has been NO ide changes in that time either (only mvel and compiler).


> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 05:19:18 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 30 Aug 2007 05:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10438667.1188465558289.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374560 ] 
            
Ahti Kitsik commented on JBRULES-1145:
--------------------------------------

for me, any code after
	update ( m );
is ignored (no suspend or breakpoints).

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 06:04:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1634) Finish the
 user email
 verification after registration and when a user change his email
In-Reply-To: <21470014.1187352668490.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21649480.1188468258617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1634?page=comments#action_12374563 ] 
            
Thomas Heute commented on JBPORTAL-1634:
----------------------------------------

The missing bits are:
- When a user click on the link it should apply the new email and print a success message
- The full url must be provided to the user when clicking

> Finish the user email verification after registration and when a user change his email 
> ---------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1634
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1634
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 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 lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1658) Let the identity
 UI configuration specify multiple validators on a field
Message-ID: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>

Let the identity UI configuration specify multiple validators on a field
------------------------------------------------------------------------

                 Key: JBPORTAL-1658
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Thomas Heute


In the XML configuration for identity portlets we should have:

<validators>
 <validator>...</validator>
 <validator>...</validator>
</validators>



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1658) Let the identity
 UI configuration specify multiple validators on a field
In-Reply-To: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26548358.1188468513642.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1658?page=all ]

Thomas Heute updated JBPORTAL-1658:
-----------------------------------

      Component/s: Portal Core
    Fix Version/s: 2.8 Final
         Assignee: Emanuel Muckenhuber

> Let the identity UI configuration specify multiple validators on a field
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1658
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets we should have:
> <validators>
>  <validator>...</validator>
>  <validator>...</validator>
> </validators>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Ahti Kitsik (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10469598.1188468513807.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=comments#action_12374564 ] 
            
Ahti Kitsik commented on JBRULES-1145:
--------------------------------------

Call to frame.getFactory().getKnownVariables() is throwing this:

java.lang.NullPointerException
	at org.mvel.integration.impl.BaseVariableResolverFactory.getKnownVariables(BaseVariableResolverFactory.java:83)
	at org.drools.base.mvel.MVELDebugHandler$MVELDebugger.onBreak(MVELDebugHandler.java:74)
	at org.mvel.debug.DebuggerContext.checkBreak(DebuggerContext.java:81)
	at org.mvel.MVELRuntime.execute(MVELRuntime.java:78)
	at org.mvel.MVEL.executeDebugger(MVEL.java:344)
	at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:39)
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550)
	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:434)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:396)
	at org.drools.examples.HelloWorldExample.main(HelloWorldExample.java:27)


> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.1
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 06:08:33 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1659) Allow for
 multiple defaut roles when a user is created
Message-ID: <31676308.1188468513944.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow for multiple defaut roles when a user is created
------------------------------------------------------

                 Key: JBPORTAL-1659
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1659
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


In the XML configuration for identity portlets, we should be able to specify multiple default 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 lists.jboss.org  Thu Aug 30 06:10:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1658) Let the identity
 UI configuration specify multiple validators on a field
In-Reply-To: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2107753.1188468618502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1658?page=all ]

Thomas Heute updated JBPORTAL-1658:
-----------------------------------

    Component/s: Portal Identity
                     (was: Portal Core)

> Let the identity UI configuration specify multiple validators on a field
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1658
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets we should have:
> <validators>
>  <validator>...</validator>
>  <validator>...</validator>
> </validators>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:14:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1660) Identity portlet
 configuration should allow to specify static and dynamic values
Message-ID: <19244245.1188468858466.JavaMail.jira@cloud.prod.atl2.jboss.com>

Identity portlet configuration should allow to specify static and dynamic values
--------------------------------------------------------------------------------

                 Key: JBPORTAL-1660
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1660
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


In the configuration file we should have something like:
<values>
    <value key="foo">Foo</value>
    <value key="bar">Bar</value>
</values>

Foo and Bar should be localized, it should check in the resource bundle for something like:
SOMEPREFIX_Foo and default to "Foo" if it doesn't exist.

For dynamic values like themes, locales and timezones we should allow the following syntax:
<values name="org.jboss.portal.THEMES"/>
<values name="org.jboss.portal.LOCALES"/>
<values name="org.jboss.portal.TIMEZONES"/>

(All the name still have to be defined, those are just 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 lists.jboss.org  Thu Aug 30 06:18:20 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:18:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1661) Remind password
 feature should be easy to turn off
Message-ID: <26688602.1188469100464.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remind password feature should be easy to turn off
--------------------------------------------------

                 Key: JBPORTAL-1661
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1661
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Emanuel Muckenhuber
             Fix For: 2.8 Final


Since the remind password feature requires a configured SMTP server, some users may want to disable it.

While it would work on Fedora out of the box (and probably other distro too) it could be an issue for Windows 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 lists.jboss.org  Thu Aug 30 06:20:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 06:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1662) Figure out the
 deployment issue with workflow
Message-ID: <31613999.1188469218191.JavaMail.jira@cloud.prod.atl2.jboss.com>

Figure out the deployment issue with workflow
---------------------------------------------

                 Key: JBPORTAL-1662
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1662
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
            Reporter: Thomas Heute
         Assigned To: Thomas Heute
             Fix For: 2.8 Final


As of now, the workflow service is started by the CMS so it would work only if the CMS service is running.

workflow.sar being deployed after portal-identity.sar (alphabetic order) we cannot easily start it in workflow.sar (i guess that it was the motivation for starting it in portal-cms.sar) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 06:25:18 2007
From: jira-events at lists.jboss.org (Aaman Lamba (JIRA))
Date: Thu, 30 Aug 2007 06:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18219604.1188469518749.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374566 ] 
            
Aaman Lamba commented on JBAS-4491:
-----------------------------------

Is there any update to this issue - it is pretty much a showstopper for us.The error message we receive on JBoss Startup is reproduced below, and quite similar to the original report.

===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: D:\jboss-5.0.0.Beta2

  JAVA: d:\sun\sdk\jdk\bin\java

  JAVA_OPTS:  -Dprogram.name=run.bat -server -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dsun.rmi.dgc.cl
ient.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

  CLASSPATH: d:\sun\sdk\jdk\lib\tools.jar;D:\jboss-5.0.0.Beta2\bin\run.jar

===============================================================================

14:55:46,344 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
14:55:46,376 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_
Beta2 date=200704060017)
14:55:46,376 INFO  [ServerImpl] Home Dir: D:\jboss-5.0.0.Beta2
14:55:46,376 INFO  [ServerImpl] Home URL: file:/D:/jboss-5.0.0.Beta2/
14:55:46,376 INFO  [ServerImpl] Library URL: file:/D:/jboss-5.0.0.Beta2/lib/
14:55:46,391 INFO  [ServerImpl] Patch URL: null
14:55:46,391 INFO  [ServerImpl] Server Name: default
14:55:46,391 INFO  [ServerImpl] Server Home Dir: D:\jboss-5.0.0.Beta2\server\default
14:55:46,391 INFO  [ServerImpl] Server Home URL: file:/D:/jboss-5.0.0.Beta2/server/default/
14:55:46,391 INFO  [ServerImpl] Server Data Dir: D:\jboss-5.0.0.Beta2\server\default\data
14:55:46,391 INFO  [ServerImpl] Server Temp Dir: D:\jboss-5.0.0.Beta2\server\default\tmp
14:55:46,391 INFO  [ServerImpl] Server Config URL: file:/D:/jboss-5.0.0.Beta2/server/default/conf/
14:55:46,391 INFO  [ServerImpl] Server Library URL: file:/D:/jboss-5.0.0.Beta2/server/default/lib/
14:55:46,391 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
14:55:46,422 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/D:/jboss-5.0.0.Beta2/ser
ver/default/conf/bootstrap-beans.xml
14:55:47,266 INFO  [ProfileImpl] Using profile root:D:\jboss-5.0.0.Beta2\server\default
14:55:48,860 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilte
r state=Described
java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
        at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
        at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
        at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
        at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentM
etaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
        at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(
AbstractMetaDataContext.java:280)
        at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(M
etaDataRetrievalToMetaDataBridge.java:159)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOP
ConstructorJoinpoint.java:202)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPCon
structorJoinpoint.java:172)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMe
taData(AOPConstructorJoinpoint.java:152)
        at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJ
oinpoint.java:99)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(Kerne
lControllerContextAction.java:103)
        at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAc
tion.java:52)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelCon
trollerContextAction.java:197)
        at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControlle
rContextAction.java:136)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerC
ontextActions.java:51)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.
java:233)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:44
5)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:5
55)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:4
89)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
        at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeplo
yer.java:302)
        at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDepl
oyer.java:272)
        at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.
java:119)
        at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:6
4)
        at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)

        at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146
)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBoots
trap.java:295)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBo
otstrap.java:222)
        at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
        at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
        at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
        at org.jboss.Main.boot(Main.java:210)
        at org.jboss.Main$1.run(Main.java:522)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
        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 org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
        ... 35 more
14:55:49,328 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
14:55:49,328 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.6.0-b105,Sun Microsystems Inc.

14:55:49,328 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
14:55:49,360 INFO  [JMXKernel] Legacy JMX core initialized
Failed to boot JBoss:
java.lang.RuntimeException: Exception during Bootstrap
        at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
        at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
        at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
        at org.jboss.Main.boot(Main.java:210)
        at org.jboss.Main$1.run(Main.java:522)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments
(SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}

VFSBootstrapScanner
 -> DeploymentFilter{Configured:**ERROR**}

VFSDeployerScanner
 -> DeploymentFilter{Configured:**ERROR**}

VFSDeploymentScanner
 -> DeploymentFilter{Configured:**ERROR**}


*** CONTEXTS IN ERROR: Name -> Error

DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;


        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileSer
viceBootstrap.java:389)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBo
otstrap.java:236)
        at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
        ... 5 more
14:57:19,568 INFO  [ServerImpl] JBoss SHUTDOWN
14:57:19,568 INFO  [ServerImpl] Undeploying all packages
Shutting down Microcontainer
14:57:19,615 INFO  [ServerImpl] Shutdown complete
Shutdown complete
Halting VM
Terminate batch job (Y/N)? y
============


> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 06:41:46 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 06:41:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4494273.1188470506360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4491?page=all ]

Adrian Brock updated JBAS-4491:
-------------------------------

    Comment: was deleted

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 06:41:46 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 06:41:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3014601.1188470506697.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4491?page=all ]

Adrian Brock updated JBAS-4491:
-------------------------------

    Comment: was deleted

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 06:50:27 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Thu, 30 Aug 2007 06:50:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18964911.1188471027780.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374568 ] 
            
Adrian Brock commented on JBAS-4491:
------------------------------------

JIRA is the release notes NOT a discussion forum.
I've deleted the redundant comments.

There are perfectly good discussion forums here:
http://www.jboss.com/index.html?module=bb
if you want help.

As for this bug report.
1) It is obviously a JDK bug in Sun's 1.6, something that works in 1.5  but not 1.6 is a regression that should be
reported to the JDK provider.
2) JBoss5 doesn't even compile on JDK6 (due to changes in interfaces, e.g. the jdbc interfaces) 
and certainly hasn't been tested on it either

It is planned to make JBoss5 work with JDK6 including regular regression testing.

This bug report will almost certainly be closed as "Won't Fix" once we know for certain that this is JDK bug
in early releases of Sun's 1.6 JDK.

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 07:09:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 07:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1626) FIrst access to
 a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14921485.1188472158342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=all ]

Thomas Heute updated JBPORTAL-1626:
-----------------------------------

    Priority: Critical  (was: Major)

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 07:11:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 07:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24578480.1188472278366.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12374569 ] 
            
Thomas Heute commented on JBPORTAL-1626:
----------------------------------------

It's actually breaking with JBoss AS 4.2.1.GA (works fine with 4.0.5)

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 07:38:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 07:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19048467.1188473898474.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4563?page=comments#action_12374570 ] 
            
Dimitris Andreadis commented on JBAS-4563:
------------------------------------------

We need to hurry up with the hibernate upgrades.

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 07:40:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 07:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.2
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33350245.1188474018228.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374571 ] 
            
Dimitris Andreadis commented on JBAS-4564:
------------------------------------------

Same here, we have limited time to perform library updates and solve any integration issues that may come up.

> Hibernate EntityManager 3.3.2
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 08:01:20 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 30 Aug 2007 08:01:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1658) Let the
 identity UI configuration specify multiple validators on a field
In-Reply-To: <15741597.1188468513166.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14697399.1188475280457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1658?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1658.
-------------------------------------------

    Resolution: Done

example usage: validatorId="metadata.email.validators[0]" or validatorId="metadataservice.email.validator" to get the first validator of the list

> Let the identity UI configuration specify multiple validators on a field
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1658
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1658
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets we should have:
> <validators>
>  <validator>...</validator>
>  <validator>...</validator>
> </validators>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 08:16:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Aug 2007 08:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-585) FD_SOCK: make
 fetching of cache asynchronous
Message-ID: <29535831.1188476178345.JavaMail.jira@cloud.prod.atl2.jboss.com>

FD_SOCK: make fetching of cache asynchronous
--------------------------------------------

                 Key: JGRP-585
                 URL: http://jira.jboss.com/jira/browse/JGRP-585
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.6


FD_SOCK fetches the cache *synchronously* on down(VIEW_CHANGE). This blocks until the cache has been received, blocking down() and therefore other down calls. This could for example block a JOIN_RSP to a new joiner, causing the JOIN_REQ to fail.
[Vladimir]
Trying to dig into the trenches in order to understand why exactly is ConcurrentStartupTest failing if we switch up and down view sending in GMS#installView! I noticed that FD_SOCK in down for VIEW_CHANGE event does a very unusual thing: synchronous mcast invocation and it does it repeatedly until succeeds in getting cache contents or timeouts. But it does not look like it is 100% necessary to do this? Can't we abstract getting cache contents into a task that is run on a timer until we get a result? So we effectively we make getting cache contents asynchronous that does not potentially block view installation for quite a while because as it is now - this is what is happening.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 08:30:18 2007
From: jira-events at lists.jboss.org (Matthias Raab (JIRA))
Date: Thu, 30 Aug 2007 08:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-96) SUN JDK 1.5 on client
 side and IBM JDK 1.5 on server side doesn't work together
Message-ID: <2193288.1188477018845.JavaMail.jira@cloud.prod.atl2.jboss.com>

SUN JDK 1.5 on client side and IBM JDK 1.5 on server side doesn't work together
-------------------------------------------------------------------------------

                 Key: JBSER-96
                 URL: http://jira.jboss.com/jira/browse/JBSER-96
             Project: JBoss Serialization
          Issue Type: Bug
    Affects Versions: 1.0.3 GA
         Environment: 1. Client: Windows, SUN JDK 1.5.0_12, JBoss Client
2. Server: AS/400 with i5, IBM JKD 1.5 (J9), JBoss Server
            Reporter: Matthias Raab
         Assigned To: Clebert Suconic
            Priority: Critical


Failure during serialization on client side: "Current classpath has lesser fields on java.math.BigDecimal than its original version"
Stacktrace
java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at de.carus.cjfc.tfc.dto.TMDTOExchange.readExternal(TMDTOExchange.java:3092)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78)
	at org.jboss.invocation.http.interfaces.Util.invoke(Util.java:169)
	at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:103)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
	at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
	at $Proxy5.read(Unknown Source)
	at de.carus.cjfc.tfc.bu.ejb.TMUseCaseMgrEJBClient.read(TMUseCaseMgrEJBClient.java:246)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.executeSearch(TMUseCaseMgr.java:1702)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.search(TMUseCaseMgr.java:1686)
	at de.carus.cjfc.tfc.bu.model.TMModelContext.search(TMModelContext.java:212)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:427)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:400)
	at de.alea.amc.core.bu.usecase.center.UCCompanySelector.find(UCCompanySelector.java:177)
	at de.alea.amc.core.bu.model.user.MAMCUser.getAllowedSystemClients(MAMCUser.java:529)
	at de.alea.amc.core.pr.swt.user.LoginDialog.okPressed(LoginDialog.java:207)
	at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:464)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:616)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
	at org.eclipse.jface.window.Window.open(Window.java:796)
	at de.alea.amc.core.pr.swt.user.LoginAction.run(LoginAction.java:30)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.runStartActions(AmcRunnable.java:133)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.run(AmcRunnable.java:52)
	at de.alea.amc.pr.swt.rcpframe.AMCSafeRunnableRunner.run(AMCSafeRunnableRunner.java:48)
	at de.alea.amc.pr.AmcRunnable.run(AmcRunnable.java:165)
	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.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAppContainer.java:533)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:155)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 63 more
Caused by: java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 67 more
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 81 more
Caused by: java.io.IOException: Current classpath has lesser fields on java.math.BigDecimal than its original version
	at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 85 more
java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at de.carus.cjfc.tfc.dto.TMDTOExchange.readExternal(TMDTOExchange.java:3092)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78)
	at org.jboss.invocation.http.interfaces.Util.invoke(Util.java:169)
	at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:103)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
	at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
	at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
	at $Proxy5.read(Unknown Source)
	at de.carus.cjfc.tfc.bu.ejb.TMUseCaseMgrEJBClient.read(TMUseCaseMgrEJBClient.java:246)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.executeSearch(TMUseCaseMgr.java:1702)
	at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.search(TMUseCaseMgr.java:1686)
	at de.carus.cjfc.tfc.bu.model.TMModelContext.search(TMModelContext.java:212)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:427)
	at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:400)
	at de.alea.amc.core.bu.usecase.center.UCCompanySelector.find(UCCompanySelector.java:177)
	at de.alea.amc.core.bu.model.user.MAMCUser.getAllowedSystemClients(MAMCUser.java:529)
	at de.alea.amc.core.pr.swt.user.LoginDialog.okPressed(LoginDialog.java:207)
	at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:464)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:616)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
	at org.eclipse.jface.window.Window.open(Window.java:796)
	at de.alea.amc.core.pr.swt.user.LoginAction.run(LoginAction.java:30)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.runStartActions(AmcRunnable.java:133)
	at de.alea.amc.pr.AmcRunnable$ApplicationStarter.run(AmcRunnable.java:52)
	at de.alea.amc.pr.swt.rcpframe.AMCSafeRunnableRunner.run(AMCSafeRunnableRunner.java:48)
	at de.alea.amc.pr.AmcRunnable.run(AmcRunnable.java:165)
	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.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAppContainer.java:533)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:155)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
	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.equinox.launcher.Main.invokeFramework(Main.java:504)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 63 more
Caused by: java.io.IOException
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 67 more
Caused by: java.lang.reflect.InvocationTargetException
	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.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
	... 81 more
Caused by: java.io.IOException: Current classpath has lesser fields on java.math.BigDecimal than its original version
	at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
	at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at java.util.ArrayList.readObject(ArrayList.java:591)
	... 85 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 lists.jboss.org  Thu Aug 30 08:38:18 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 30 Aug 2007 08:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
In-Reply-To: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2375390.1188477498396.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4643?page=comments#action_12374586 ] 
            
Alexey Loubyansky commented on JBAS-4643:
-----------------------------------------

For the org.jboss.test.xml.DDValidatorUnitTestCase there is still one test failing because the XML is referencing http://www.jboss.org/j2ee/schema/jboss_5_0.xsd which does not exist. The file is
trunk\testsuite\output\resources\naming\jar\META-INF\jboss.xml

> Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
> -----------------------------------------------------------
>
>                 Key: JBAS-4643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
> junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)
>  9.162 
> testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
> junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)
>  2.797 
> testJBossCmpJdbc Success  0.994 
> testWebXml Success  1.930 
> testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
> junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)
>  0.455 
> testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
> junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)
>  0.635 
> testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
> junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)
>  0.825 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 09:15:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 09:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-763) Release 2.2.1.GA
In-Reply-To: <16838776.1183317717648.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22538350.1188479729128.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-763?page=comments#action_12374595 ] 
            
Dimitris Andreadis commented on JBREM-763:
------------------------------------------

I suppose this can be closed?

> Release 2.2.1.GA
> ----------------
>
>                 Key: JBREM-763
>                 URL: http://jira.jboss.com/jira/browse/JBREM-763
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.GA
>
>
> This release contains bug fixes for JBREM-747, JBREM-748, JBREM-751, and JBREM-761.  It is intended for inclusion with community JBossAS 4.2.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 lists.jboss.org  Thu Aug 30 09:29:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 09:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1147) Release 4.0.1
	version
Message-ID: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release 4.0.1 version
---------------------

                 Key: JBRULES-1147
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
             Project: JBoss Rules
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Fernando Meyer
             Fix For: 4.0.1


Release 4.0.1 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 lists.jboss.org  Thu Aug 30 09:55:18 2007
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 30 Aug 2007 09:55:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4643) Fix
 org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
In-Reply-To: <17985950.1188321978295.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30097897.1188482118265.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4643?page=comments#action_12374607 ] 
            
Alexey Loubyansky commented on JBAS-4643:
-----------------------------------------

The SingletonSchemaBindingResolverUnitTestCase was missing an XSD. It's fixed now.

> Fix org.jboss.test.xml.DDValidatorUnitTestCase (5 failures)
> -----------------------------------------------------------
>
>                 Key: JBAS-4643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4643
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Alexey Loubyansky
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> testEjbJar Failure 5 from 165 are invalid expected:<0> but was:<5>
> junit.framework.AssertionFailedError: 5 from 165 are invalid expected:<0> but was:<5>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testEjbJar(DDValidatorUnitTestCase.java:76)
>  9.162 
> testJBossXml Failure 3 from 143 are invalid expected:<0> but was:<3>
> junit.framework.AssertionFailedError: 3 from 143 are invalid expected:<0> but was:<3>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossXml(DDValidatorUnitTestCase.java:81)
>  2.797 
> testJBossCmpJdbc Success  0.994 
> testWebXml Success  1.930 
> testJBossWeb Failure 4 from 39 are invalid expected:<0> but was:<4>
> junit.framework.AssertionFailedError: 4 from 39 are invalid expected:<0> but was:<4>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:96)
>  0.455 
> testApplicationXml Failure 8 from 50 are invalid expected:<0> but was:<8>
> junit.framework.AssertionFailedError: 8 from 50 are invalid expected:<0> but was:<8>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testApplicationXml(DDValidatorUnitTestCase.java:101)
>  0.635 
> testJBossApp Failure 2 from 37 are invalid expected:<0> but was:<2>
> junit.framework.AssertionFailedError: 2 from 37 are invalid expected:<0> but was:<2>
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:115)
> 	at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossApp(DDValidatorUnitTestCase.java:106)
>  0.825 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 10:09:18 2007
From: jira-events at lists.jboss.org (eymeric vieuille (JIRA))
Date: Thu, 30 Aug 2007 10:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
Message-ID: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>

Out of memory exception asserting more than 100 facts
-----------------------------------------------------

                 Key: JBRULES-1148
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions:  4.0.0.GA
         Environment: JDK 1.5; OS = Windows 2000 pro.

For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
            Reporter: eymeric vieuille
         Assigned To: Mark Proctor
             Fix For:  4.0.0.GA
         Attachments: Out_Of_Memory_Test.zip

I got a java.lang.OutOfMemoryException when I assert more than 100 objects.

I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)

You can see there logs obtained launching the sample project main class :

Launching RULES ENGINE
100 Facts
Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 10:09:18 2007
From: jira-events at lists.jboss.org (eymeric vieuille (JIRA))
Date: Thu, 30 Aug 2007 10:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
In-Reply-To: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18310066.1188482958821.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1148?page=all ]

eymeric vieuille updated JBRULES-1148:
--------------------------------------

    Attachment: Out_Of_Memory_Test.zip

Sample project.

> Out of memory exception asserting more than 100 facts
> -----------------------------------------------------
>
>                 Key: JBRULES-1148
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: JDK 1.5; OS = Windows 2000 pro.
> For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
>            Reporter: eymeric vieuille
>         Assigned To: Mark Proctor
>             Fix For:  4.0.0.GA
>
>         Attachments: Out_Of_Memory_Test.zip
>
>
> I got a java.lang.OutOfMemoryException when I assert more than 100 objects.
> I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)
> You can see there logs obtained launching the sample project main class :
> Launching RULES ENGINE
> 100 Facts
> Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
> Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 10:17:25 2007
From: jira-events at lists.jboss.org (Fernando Meyer (JIRA))
Date: Thu, 30 Aug 2007 10:17:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1147) Release 4.0.1
	version
In-Reply-To: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26023052.1188483445535.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1147?page=comments#action_12374615 ] 
            
Fernando Meyer commented on JBRULES-1147:
-----------------------------------------

created tag https://svn.labs.jboss.com/labs/jbossrules/tags/4.0.1.14754GA 

> Release 4.0.1 version
> ---------------------
>
>                 Key: JBRULES-1147
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Release 4.0.1 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 lists.jboss.org  Thu Aug 30 10:19:19 2007
From: jira-events at lists.jboss.org (Work Related (JIRA))
Date: Thu, 30 Aug 2007 10:19:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1663) can images be
	used in tabs
Message-ID: <20788483.1188483559584.JavaMail.jira@cloud.prod.atl2.jboss.com>

can images be used in tabs
--------------------------

                 Key: JBPORTAL-1663
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1663
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.1 Final
            Reporter: Work Related
            Priority: Optional


can anyone please tell me if we can use images as tabs in jboss portal 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 lists.jboss.org  Thu Aug 30 10:22:49 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Thu, 30 Aug 2007 10:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1663) can images be
	used in tabs
In-Reply-To: <20788483.1188483559584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2577759.1188483769399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1663?page=all ]

Thomas Heute resolved JBPORTAL-1663.
------------------------------------

    Resolution: Rejected

For questions please use the forum, Jira is used to report confirmed bugs

> can images be used in tabs
> --------------------------
>
>                 Key: JBPORTAL-1663
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1663
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.1 Final
>            Reporter: Work Related
>            Priority: Optional
>
> can anyone please tell me if we can use images as tabs in jboss portal 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 lists.jboss.org  Thu Aug 30 10:29:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 10:29:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-412) Look into source
 level dependencies with maven
Message-ID: <27076786.1188484158359.JavaMail.jira@cloud.prod.atl2.jboss.com>

Look into source level dependencies with maven
----------------------------------------------

                 Key: JBBUILD-412
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-412
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - Maint 2007


Steve brought up the issue of not being able to use intermodule dependencies without installing the modules.  In other words, you should be able to make a fix in one module, and then be able to use the fix in another module without installing the first module.
Also, you should be able to run a mvn compile of a multi-module project with inter-module deps with an empty 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 lists.jboss.org  Thu Aug 30 10:31:18 2007
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Thu, 30 Aug 2007 10:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15511388.1188484278348.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374619 ] 
            
Remy Maucherat commented on JBAS-4562:
--------------------------------------

Right, even if some functionality is only API complete at the moment (the Comet IO fonctionality updates), the core functionality is ok, so I can update the AS 5 branch to it sooner rather than later (before the end of the week would be ok ?).

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 10:38:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 10:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4562) Track jboss and
 thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
In-Reply-To: <28466873.1184775407204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21984324.1188484698353.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4562?page=comments#action_12374620 ] 
            
Dimitris Andreadis commented on JBAS-4562:
------------------------------------------

That's fine.

> Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.Beta3
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4562
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4562
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Track JBoss and thirdparty dependencies upgrades as subtasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 11:04:19 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Aug 2007 11:04:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25393062.1188486259887.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]

Bela Ban updated JGRP-507:
--------------------------

    Fix Version/s: 2.6

Will look at it in the 2.6 release time frame 9although it won't probably get fixed in 2.6 as 2.6 doesn't seem to have this problem).

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1, 2.3, 2.4.1 SP2, 2.4.1 SP1, 2.4.1, 2.4, 2.2.9 SP4, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.2.7 SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Thu Aug 30 11:11:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 30 Aug 2007 11:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11559250.1188486678301.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-507?page=comments#action_12374627 ] 
            
Galder Zamarreno commented on JGRP-507:
---------------------------------------

Bela, it was fixed in 2.4.1.SP3. I just posted the link to the case that raised 
this a few months ago.

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1, 2.3, 2.4.1 SP2, 2.4.1 SP1, 2.4.1, 2.4, 2.2.9 SP4, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.2.7 SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Thu Aug 30 11:40:54 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 11:40:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
In-Reply-To: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18794185.1188488454529.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1148?page=all ]

Edson Tirelli reassigned JBRULES-1148:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Out of memory exception asserting more than 100 facts
> -----------------------------------------------------
>
>                 Key: JBRULES-1148
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: JDK 1.5; OS = Windows 2000 pro.
> For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
>            Reporter: eymeric vieuille
>         Assigned To: Edson Tirelli
>             Fix For:  4.0.0.GA
>
>         Attachments: Out_Of_Memory_Test.zip
>
>
> I got a java.lang.OutOfMemoryException when I assert more than 100 objects.
> I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)
> You can see there logs obtained launching the sample project main class :
> Launching RULES ENGINE
> 100 Facts
> Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
> Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 11:42:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 11:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1148) Out of memory
 exception asserting more than 100 facts
In-Reply-To: <12280490.1188482958614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9311341.1188488538418.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1148?page=all ]

Edson Tirelli updated JBRULES-1148:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was:  4.0.0.GA)

> Out of memory exception asserting more than 100 facts
> -----------------------------------------------------
>
>                 Key: JBRULES-1148
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1148
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>         Environment: JDK 1.5; OS = Windows 2000 pro.
> For the version of Drools, I am not sure but that is the 4.0 version that you can currently download here : http://labs.jboss.com/drools/downloads/;jsessionid=4BFE39586019C6B98C9B4EDE22C539F0
>            Reporter: eymeric vieuille
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.2
>
>         Attachments: Out_Of_Memory_Test.zip
>
>
> I got a java.lang.OutOfMemoryException when I assert more than 100 objects.
> I gave you a sample project tracing trucks progression between your firm and the purveyor thanks to message received from trucks. (for more details see on the JBoss forum reference given)
> You can see there logs obtained launching the sample project main class :
> Launching RULES ENGINE
> 100 Facts
> Facts : [OUT:TLSE:PRS::2007-04-20T23:00:00Z, OFF:TLSE:PRS::2007-04-20T23:00:01Z, ON:TLSE:PRS::2007-04-20T23:00:02Z, IN:TLSE:PRS::2007-04-20T23:00:03Z, OUT:TLSE:PRS::2007-04-20T23:01:00Z, OFF:TLSE:PRS::2007-04-20T23:01:01Z, ON:TLSE:PRS::2007-04-20T23:01:02Z, IN:TLSE:PRS::2007-04-20T23:01:03Z, OUT:TLSE:PRS::2007-04-20T23:02:00Z, OFF:TLSE:PRS::2007-04-20T23:02:01Z, ON:TLSE:PRS::2007-04-20T23:02:02Z, IN:TLSE:PRS::2007-04-20T23:02:03Z, OUT:TLSE:PRS::2007-04-20T23:03:00Z, OFF:TLSE:PRS::2007-04-20T23:03:01Z, ON:TLSE:PRS::2007-04-20T23:03:02Z, IN:TLSE:PRS::2007-04-20T23:03:03Z, OUT:TLSE:PRS::2007-04-20T23:04:00Z, OFF:TLSE:PRS::2007-04-20T23:04:01Z, ON:TLSE:PRS::2007-04-20T23:04:02Z, IN:TLSE:PRS::2007-04-20T23:04:03Z, OUT:TLSE:PRS::2007-04-20T23:05:00Z, OFF:TLSE:PRS::2007-04-20T23:05:01Z, ON:TLSE:PRS::2007-04-20T23:05:02Z, IN:TLSE:PRS::2007-04-20T23:05:03Z, OUT:TLSE:PRS::2007-04-20T23:06:00Z, OFF:TLSE:PRS::2007-04-20T23:06:01Z, ON:TLSE:PRS::2007-04-20T23:06:02Z, IN:TLSE:PRS::2007-04-20T23:06:03Z, OUT:TLSE:PRS::2007-04-20T23:07:00Z, OFF:TLSE:PRS::2007-04-20T23:07:01Z, ON:TLSE:PRS::2007-04-20T23:07:02Z, IN:TLSE:PRS::2007-04-20T23:07:03Z, OUT:TLSE:PRS::2007-04-20T23:08:00Z, OFF:TLSE:PRS::2007-04-20T23:08:01Z, ON:TLSE:PRS::2007-04-20T23:08:02Z, IN:TLSE:PRS::2007-04-20T23:08:03Z, OUT:TLSE:PRS::2007-04-20T23:09:00Z, OFF:TLSE:PRS::2007-04-20T23:09:01Z, ON:TLSE:PRS::2007-04-20T23:09:02Z, IN:TLSE:PRS::2007-04-20T23:09:03Z, OUT:TLSE:PRS::2007-04-20T23:10:00Z, OFF:TLSE:PRS::2007-04-20T23:10:01Z, ON:TLSE:PRS::2007-04-20T23:10:02Z, IN:TLSE:PRS::2007-04-20T23:10:03Z, OUT:TLSE:PRS::2007-04-20T23:11:00Z, OFF:TLSE:PRS::2007-04-20T23:11:01Z, ON:TLSE:PRS::2007-04-20T23:11:02Z, IN:TLSE:PRS::2007-04-20T23:11:03Z, OUT:TLSE:PRS::2007-04-20T23:12:00Z, OFF:TLSE:PRS::2007-04-20T23:12:01Z, ON:TLSE:PRS::2007-04-20T23:12:02Z, IN:TLSE:PRS::2007-04-20T23:12:03Z, OUT:TLSE:PRS::2007-04-20T23:13:00Z, OFF:TLSE:PRS::2007-04-20T23:13:01Z, ON:TLSE:PRS::2007-04-20T23:13:02Z, IN:TLSE:PRS::2007-04-20T23:13:03Z, OUT:TLSE:PRS::2007-04-20T23:14:00Z, OFF:TLSE:PRS::2007-04-20T23:14:01Z, ON:TLSE:PRS::2007-04-20T23:14:02Z, IN:TLSE:PRS::2007-04-20T23:14:03Z, OUT:TLSE:PRS::2007-04-20T23:15:00Z, OFF:TLSE:PRS::2007-04-20T23:15:01Z, ON:TLSE:PRS::2007-04-20T23:15:02Z, IN:TLSE:PRS::2007-04-20T23:15:03Z, OUT:TLSE:PRS::2007-04-20T23:16:00Z, OFF:TLSE:PRS::2007-04-20T23:16:01Z, ON:TLSE:PRS::2007-04-20T23:16:02Z, IN:TLSE:PRS::2007-04-20T23:16:03Z, OUT:TLSE:PRS::2007-04-20T23:17:00Z, OFF:TLSE:PRS::2007-04-20T23:17:01Z, ON:TLSE:PRS::2007-04-20T23:17:02Z, IN:TLSE:PRS::2007-04-20T23:17:03Z, OUT:TLSE:PRS::2007-04-20T23:18:00Z, OFF:TLSE:PRS::2007-04-20T23:18:01Z, ON:TLSE:PRS::2007-04-20T23:18:02Z, IN:TLSE:PRS::2007-04-20T23:18:03Z, OUT:TLSE:PRS::2007-04-20T23:19:00Z, OFF:TLSE:PRS::2007-04-20T23:19:01Z, ON:TLSE:PRS::2007-04-20T23:19:02Z, IN:TLSE:PRS::2007-04-20T23:19:03Z, OUT:TLSE:PRS::2007-04-20T23:20:00Z, OFF:TLSE:PRS::2007-04-20T23:20:01Z, ON:TLSE:PRS::2007-04-20T23:20:02Z, IN:TLSE:PRS::2007-04-20T23:20:03Z, OUT:TLSE:PRS::2007-04-20T23:21:00Z, OFF:TLSE:PRS::2007-04-20T23:21:01Z, ON:TLSE:PRS::2007-04-20T23:21:02Z, IN:TLSE:PRS::2007-04-20T23:21:03Z, OUT:TLSE:PRS::2007-04-20T23:22:00Z, OFF:TLSE:PRS::2007-04-20T23:22:01Z, ON:TLSE:PRS::2007-04-20T23:22:02Z, IN:TLSE:PRS::2007-04-20T23:22:03Z, OUT:TLSE:PRS::2007-04-20T23:23:00Z, OFF:TLSE:PRS::2007-04-20T23:23:01Z, ON:TLSE:PRS::2007-04-20T23:23:02Z, IN:TLSE:PRS::2007-04-20T23:23:03Z, OUT:TLSE:PRS::2007-04-20T23:24:00Z, OFF:TLSE:PRS::2007-04-20T23:24:01Z, ON:TLSE:PRS::2007-04-20T23:24:02Z, IN:TLSE:PRS::2007-04-20T23:24:03Z]
> Add object : OUT:TLSE:PRS::2007-04-20T23:00:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:00:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:00:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:00:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:01:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:01:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:01:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:01:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:02:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:02:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:02:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:02:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:03:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:03:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:03:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:03:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:04:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:04:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:04:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:04:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:05:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:05:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:05:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:05:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:06:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:06:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:06:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:06:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:07:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:07:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:07:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:07:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:08:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:08:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:08:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:08:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:09:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:09:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:09:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:09:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:10:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:10:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:10:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:10:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:11:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:11:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:11:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:11:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:12:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:12:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:12:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:12:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:13:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:13:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:13:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:13:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:14:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:14:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:14:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:14:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:15:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:15:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:15:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:15:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:16:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:16:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:16:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:16:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:17:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:17:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:17:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:17:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:18:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:18:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:18:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:18:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:19:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:19:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:19:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:19:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:20:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:20:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:20:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:20:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:21:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:21:01Z
> Add object : ON:TLSE:PRS::2007-04-20T23:21:02Z
> Add object : IN:TLSE:PRS::2007-04-20T23:21:03Z
> Add object : OUT:TLSE:PRS::2007-04-20T23:22:00Z
> Add object : OFF:TLSE:PRS::2007-04-20T23:22:01Z
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap 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 lists.jboss.org  Thu Aug 30 11:57:18 2007
From: jira-events at lists.jboss.org (Greg Zoller (JIRA))
Date: Thu, 30 Aug 2007 11:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4491) Server startup
 failure with JDK 1.6
In-Reply-To: <30746220.1182198611683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2948109.1188489438717.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4491?page=comments#action_12374628 ] 
            
Greg Zoller commented on JBAS-4491:
-----------------------------------

Adrian,

Actually I found some more info on this "bug".  It appears to be a bug in the JDK but it is not.  Sun says that there was some ambiguity/misinterpretation of certain functionality of class loading that permitted developers to get away with some common things that strictly speaking were not part of the Java spec.  Java 6 simply closed the loophole. 

So while the behavior is not really a "bug" per se the change certainly does impact a lot of software out there and unfortunately the onus is on software providers like JBoss, not Sun, to rectify the problems this causes.  Sun is not and will not likely be open to treat this as a regression issue since in their minds the "feature" in question probably never should have worked in the first place.  Providers that don't rework the affected bits of their code may find themselves effectively stuck on JDK5.

> Server startup failure with JDK 1.6
> -----------------------------------
>
>                 Key: JBAS-4491
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4491
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>         Environment: Windows
>            Reporter: Greg Zoller
>         Attachments: Signature.java
>
>
> An out-of-the-box installation of JBoss 5.0.0 Beta2 running with JDK 1.6 produces the following exception upon startup.  Not sure the whys or wherefores but am pretty sure its not a good thing.
> 13:24:13,467 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 13:24:13,467 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta2 (build: SVNTag=JBoss_5_0_0_Beta2 date=200704060017)
> 13:24:13,467 INFO  [ServerImpl] Home Dir: C:\Program Files\jboss-5.0.0.Beta2
> 13:24:13,467 INFO  [ServerImpl] Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/
> 13:24:13,467 INFO  [ServerImpl] Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/lib/
> 13:24:13,467 INFO  [ServerImpl] Patch URL: null
> 13:24:13,467 INFO  [ServerImpl] Server Name: default
> 13:24:13,467 INFO  [ServerImpl] Server Home Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:13,467 INFO  [ServerImpl] Server Home URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/
> 13:24:13,467 INFO  [ServerImpl] Server Data Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\data
> 13:24:13,467 INFO  [ServerImpl] Server Temp Dir: C:\Program Files\jboss-5.0.0.Beta2\server\default\tmp
> 13:24:13,467 INFO  [ServerImpl] Server Config URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/
> 13:24:13,467 INFO  [ServerImpl] Server Library URL: file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/lib/
> 13:24:13,467 INFO  [ServerImpl] Root Deployment Filename: jboss-service.xml
> 13:24:13,499 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Program Files/jboss-5.0.0.Beta2/server/default/conf/bootstrap-beans.xml
> 13:24:14,831 INFO  [ProfileImpl] Using profile root:C:\Program Files\jboss-5.0.0.Beta2\server\default
> 13:24:15,913 ERROR [AbstractKernelController] Error installing to Instantiated: name=DeploymentFilter state=Described
> java.lang.IllegalStateException: Class not found: [Ljava.lang.String;
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:174)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:125)
> 	at org.jboss.metadata.spi.signature.Signature.getParametersTypes(Signature.java:292)
> 	at org.jboss.metadata.plugins.loader.reflection.AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(AnnotatedElementMetaDataLoader.java:138)
> 	at org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(AbstractMetaDataContext.java:280)
> 	at org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(MetaDataRetrievalToMetaDataBridge.java:159)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasAnnotations(AOPConstructorJoinpoint.java:202)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMethodMetaData(AOPConstructorJoinpoint.java:172)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasInstanceOrJoinpointMetaData(AOPConstructorJoinpoint.java:152)
> 	at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:99)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
> 	at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119)
> 	at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
> 	at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at java.net.URLClassLoader$1.run(Unknown Source)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.jboss.metadata.spi.signature.Signature.stringsToClasses(Signature.java:170)
> 	... 35 more
> 13:24:16,258 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,Sun Microsystems Inc.
> 13:24:16,258 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 13:24:16,305 INFO  [JMXKernel] Legacy JMX core initialized
> Failed to boot JBoss:
> java.lang.RuntimeException: Exception during Bootstrap
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
> 	at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> 	at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> 	at org.jboss.Main.boot(Main.java:210)
> 	at org.jboss.Main$1.run(Main.java:522)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> VFSBootstrapScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeployerScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> VFSDeploymentScanner
>  -> DeploymentFilter{Configured:**ERROR**}
> *** CONTEXTS IN ERROR: Name -> Error
> DeploymentFilter -> java.lang.ClassNotFoundException: [Ljava.lang.String;
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:389)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:236)
> 	at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> 	... 5 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 lists.jboss.org  Thu Aug 30 12:11:19 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-32)
 org.jboss.util.propertyeditor.PropertiesEditor should preserve the string
 text
Message-ID: <11342281.1188490279179.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.util.propertyeditor.PropertiesEditor should preserve the string text
------------------------------------------------------------------------------

                 Key: JBCOMMON-32
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-32
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: common-core
    Affects Versions: 2.0.0.GA
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: 2.2.1.GA


Many of our property editors extend org.jboss.util.propertyeditor.TextPropertyEditorSupport and operate in a reverse mode, i.e they store the string form of a property and convert to object whenever getValue() is called (rather than storing a converted object). 

In this way the string form remains intact, so there is no property replacement if you ask back the string with getAsText(). 

org.jboss.util.propertyeditor.PropertiesEditor in JBoss Common 1.x operates like this, but it was changed some time ago in jboss head (now jboss commons 2.x.)

This causes a test failure in the AS testsuite since getAsText() 
- doesn't preserve the property item order 
- resolves ${whatever} 
- includes the leading #timestamp 

I'll revert that change and essentially synch org.jboss.util.propertyeditor.PropertiesEditor  with jboss common 1.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 lists.jboss.org  Thu Aug 30 12:13:29 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-32)
 org.jboss.util.propertyeditor.PropertiesEditor should preserve the string
 text
In-Reply-To: <11342281.1188490279179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13666335.1188490409918.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-32?page=all ]

Dimitris Andreadis closed JBCOMMON-32.
--------------------------------------

    Resolution: Done

Done.

> org.jboss.util.propertyeditor.PropertiesEditor should preserve the string text
> ------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-32
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-32
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common-core
>    Affects Versions: 2.0.0.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: 2.2.1.GA
>
>
> Many of our property editors extend org.jboss.util.propertyeditor.TextPropertyEditorSupport and operate in a reverse mode, i.e they store the string form of a property and convert to object whenever getValue() is called (rather than storing a converted object). 
> In this way the string form remains intact, so there is no property replacement if you ask back the string with getAsText(). 
> org.jboss.util.propertyeditor.PropertiesEditor in JBoss Common 1.x operates like this, but it was changed some time ago in jboss head (now jboss commons 2.x.)
> This causes a test failure in the AS testsuite since getAsText() 
> - doesn't preserve the property item order 
> - resolves ${whatever} 
> - includes the leading #timestamp 
> I'll revert that change and essentially synch org.jboss.util.propertyeditor.PropertiesEditor  with jboss common 1.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 lists.jboss.org  Thu Aug 30 12:22:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 12:22:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
Message-ID: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>

Parser is only saving last CE for prefixed AND/OR 
--------------------------------------------------

                 Key: JBRULES-1149
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions:  4.0.0.GA
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli


Reported by user:

Hi,

I have a problem with this execution :

rule "Your First Rule"

when
 (or
 not Venue()
 (and v:Venue()
       l:ListeSousVenue()
       p:Param()))
then
 System.out.println("OK - 1");
end

rule "Your Second Rule"

when
 (or
 not Venue()
 (and p:Param()
       l:ListeSousVenue()
       v:Venue()))
then
   System.out.println("OK - 2");
end

In my WM, I have a Param and a ListeSousVenue but no Venue
But after execution, I have just this result :
"OK - 1"

Why the second rule doesn't execute ?

Thanks,

Vdelbart


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:33:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Thu, 30 Aug 2007 12:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4563) Hibernate
	Annotations 3.3.1
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31702140.1188491598257.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4563?page=comments#action_12374631 ] 
            
Emmanuel Bernard commented on JBAS-4563:
----------------------------------------

This does not come up at the best time for me.
If you want to start integration tests, I suggest moving to 3.3.0
3.3.1 is about bugfixing, we can move it to the next AS release (CR?)

> Hibernate Annotations 3.3.1
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:33:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Thu, 30 Aug 2007 12:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.2
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27400812.1188491598382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374632 ] 
            
Emmanuel Bernard commented on JBAS-4564:
----------------------------------------

This does not come up at the best time for me.
If you want to start integration tests, I suggest moving to 3.3.1
3.3.2 is about bugfixing and removing the evil archive browser dependency, we can move it to the next AS release (CR?)

> Hibernate EntityManager 3.3.2
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:37:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 12:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
In-Reply-To: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30487949.1188491838429.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1149?page=all ]

Edson Tirelli closed JBRULES-1149.
----------------------------------

    Fix Version/s: 4.0.1
       Resolution: Done

Fixed

> Parser is only saving last CE for prefixed AND/OR 
> --------------------------------------------------
>
>                 Key: JBRULES-1149
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Reported by user:
> Hi,
> I have a problem with this execution :
> rule "Your First Rule"
> when
>  (or
>  not Venue()
>  (and v:Venue()
>        l:ListeSousVenue()
>        p:Param()))
> then
>  System.out.println("OK - 1");
> end
> rule "Your Second Rule"
> when
>  (or
>  not Venue()
>  (and p:Param()
>        l:ListeSousVenue()
>        v:Venue()))
> then
>    System.out.println("OK - 2");
> end
> In my WM, I have a Param and a ListeSousVenue but no Venue
> But after execution, I have just this result :
> "OK - 1"
> Why the second rule doesn't execute ?
> Thanks,
> Vdelbart

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:48:18 2007
From: jira-events at lists.jboss.org (Jay Howell (JIRA))
Date: Thu, 30 Aug 2007 12:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1062) Receiving
 constraint violation when messages are persisted
Message-ID: <8759234.1188492498449.JavaMail.jira@cloud.prod.atl2.jboss.com>

Receiving constraint violation when messages are persisted
----------------------------------------------------------

                 Key: JBMESSAGING-1062
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1062
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.4.0.CR1
            Reporter: Jay Howell
         Assigned To: Tim Fox


When a message is persisted, the db throws a constraint violation.   JBM detects it as a deadlock and tries it again.  It works the second time.  This seems to be a race condition between the entries put in the JBM_MSG_REF and the JBM_MSG tables.  The entry must be fully in the JBM_MSG before the entry can be put in the JBM_MSG_REF table due to the FK constraint on MESSAGE_ID.  I also saw another customer with the same problem just after the 1.4.0 CR1 release post the same in the forums...

Here's the Log snippet...

2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
java.sql.BatchUpdateException: com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the FOREIGN KEY constraint "FK__JBM_MSG_R__MESSA__575DE8F7". The conflict occurred in database "crs5_jms_deep", table "dbo.JBM_MSG", column 'MESSAGE_ID'.
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(Unknown Source)
at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:478)
at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:519)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2911)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetryBatch(JDBCPersistenceManager.java:2791)
at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1675)
at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:3149)
at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:451)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1550)
at org.jboss.remoting.Client.invoke(Client.java:530)
at org.jboss.remoting.Client.invoke(Client.java:518)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:226)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:107)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
at org.jboss.jms.tx.ResourceManager.commitLocal(ResourceManager.java:208)
at org.jboss.jms.client.container.SessionAspect.handleCommit(SessionAspect.java:556)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect26.invoke(SessionAspect26.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossSession.commit(JBossSession.java:164)
at org.springframework.jms.connection.JmsResourceHolder.commitAll(JmsResourceHolder.java:173)
at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.afterCommit(ConnectionFactoryUtils.java:380)
at org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:90)
at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:76)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:861)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:704)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:126)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy146.commit(Unknown Source)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at com.crsoftwareinc.crs.core.domain.aop.advice.UpsertComponentIdMethodInterceptor.invoke(UpsertComponentIdMethodInterceptor.java:201)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy440.generateReportBySystemCriteria(Unknown Source)
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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy440.generateReportBySystemCriteria(Unknown Source)
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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:70)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy439.generateReportBySystemCriteria(Unknown Source)
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.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)
at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:475)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:440)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:193)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Trying again after a pause
2007-08-29 08:47:04,421 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Update worked after retry
2007-08-29 08:47:04,421 DEBUG [org.jboss.remoting.ServerInvoker] Thread pool class supplied is not an object 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 lists.jboss.org  Thu Aug 30 12:50:18 2007
From: jira-events at lists.jboss.org (Jay Howell (JIRA))
Date: Thu, 30 Aug 2007 12:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1062) Receiving
 constraint violation when messages are persisted
In-Reply-To: <8759234.1188492498449.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32641104.1188492618442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1062?page=all ]

Jay Howell updated JBMESSAGING-1062:
------------------------------------

    Workaround Description: 
open your mssql-persistence-service
change the line from
CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (CHANNEL_ID BIGINT, MESSAGE_ID BIGINT REFERENCES JBM_MSG(MESSAGE_ID), TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INT, SCHED_DELIVERY BIGINT, PRIMARY KEY(CHANNEL_ID, MESSAGE_ID))

to

CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (CHANNEL_ID BIGINT, MESSAGE_ID BIGINT, TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INT, SCHED_DELIVERY BIGINT, PRIMARY KEY(CHANNEL_ID, MESSAGE_ID))


> Receiving constraint violation when messages are persisted
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1062
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1062
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>            Reporter: Jay Howell
>         Assigned To: Tim Fox
>
> When a message is persisted, the db throws a constraint violation.   JBM detects it as a deadlock and tries it again.  It works the second time.  This seems to be a race condition between the entries put in the JBM_MSG_REF and the JBM_MSG tables.  The entry must be fully in the JBM_MSG before the entry can be put in the JBM_MSG_REF table due to the FK constraint on MESSAGE_ID.  I also saw another customer with the same problem just after the 1.4.0 CR1 release post the same in the forums...
> Here's the Log snippet...
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
> java.sql.BatchUpdateException: com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the FOREIGN KEY constraint "FK__JBM_MSG_R__MESSA__575DE8F7". The conflict occurred in database "crs5_jms_deep", table "dbo.JBM_MSG", column 'MESSAGE_ID'.
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(Unknown Source)
> at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:478)
> at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:519)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2911)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetryBatch(JDBCPersistenceManager.java:2791)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1675)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:3149)
> at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:451)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
> at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
> at org.jboss.remoting.Client.invoke(Client.java:1550)
> at org.jboss.remoting.Client.invoke(Client.java:530)
> at org.jboss.remoting.Client.invoke(Client.java:518)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:226)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:107)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
> at org.jboss.jms.tx.ResourceManager.commitLocal(ResourceManager.java:208)
> at org.jboss.jms.client.container.SessionAspect.handleCommit(SessionAspect.java:556)
> at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect26.invoke(SessionAspect26.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
> at org.jboss.jms.client.JBossSession.commit(JBossSession.java:164)
> at org.springframework.jms.connection.JmsResourceHolder.commitAll(JmsResourceHolder.java:173)
> at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.afterCommit(ConnectionFactoryUtils.java:380)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:90)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:76)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:861)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:704)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
> at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:126)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy146.commit(Unknown Source)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at com.crsoftwareinc.crs.core.domain.aop.advice.UpsertComponentIdMethodInterceptor.invoke(UpsertComponentIdMethodInterceptor.java:201)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:70)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy439.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)
> at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
> at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
> at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
> at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
> at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)
> at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:475)
> at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:440)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:193)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Trying again after a pause
> 2007-08-29 08:47:04,421 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Update worked after retry
> 2007-08-29 08:47:04,421 DEBUG [org.jboss.remoting.ServerInvoker] Thread pool class supplied is not an object 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 lists.jboss.org  Thu Aug 30 12:52:18 2007
From: jira-events at lists.jboss.org (Jay Howell (JIRA))
Date: Thu, 30 Aug 2007 12:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1062) Receiving
 constraint violation when messages are persisted
In-Reply-To: <8759234.1188492498449.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2409366.1188492738486.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1062?page=all ]

Jay Howell resolved JBMESSAGING-1062.
-------------------------------------

    Fix Version/s: 1.4.0.CR2
       Resolution: Done

This is fixed in CR2, the sql no longer has the constraint defined.

> Receiving constraint violation when messages are persisted
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1062
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1062
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.CR1
>            Reporter: Jay Howell
>         Assigned To: Tim Fox
>             Fix For: 1.4.0.CR2
>
>
> When a message is persisted, the db throws a constraint violation.   JBM detects it as a deadlock and tries it again.  It works the second time.  This seems to be a race condition between the entries put in the JBM_MSG_REF and the JBM_MSG tables.  The entry must be fully in the JBM_MSG before the entry can be put in the JBM_MSG_REF table due to the FK constraint on MESSAGE_ID.  I also saw another customer with the same problem just after the 1.4.0 CR1 release post the same in the forums...
> Here's the Log snippet...
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
> java.sql.BatchUpdateException: com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the FOREIGN KEY constraint "FK__JBM_MSG_R__MESSA__575DE8F7". The conflict occurred in database "crs5_jms_deep", table "dbo.JBM_MSG", column 'MESSAGE_ID'.
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(Unknown Source)
> at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:478)
> at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:519)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:2911)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.updateWithRetryBatch(JDBCPersistenceManager.java:2791)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1675)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:3149)
> at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208)
> at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:451)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
> at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
> at org.jboss.remoting.Client.invoke(Client.java:1550)
> at org.jboss.remoting.Client.invoke(Client.java:530)
> at org.jboss.remoting.Client.invoke(Client.java:518)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:226)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:107)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
> at org.jboss.jms.tx.ResourceManager.commitLocal(ResourceManager.java:208)
> at org.jboss.jms.client.container.SessionAspect.handleCommit(SessionAspect.java:556)
> at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect26.invoke(SessionAspect26.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.java)
> at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
> at org.jboss.jms.client.JBossSession.commit(JBossSession.java:164)
> at org.springframework.jms.connection.JmsResourceHolder.commitAll(JmsResourceHolder.java:173)
> at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.afterCommit(ConnectionFactoryUtils.java:380)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:90)
> at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:76)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:861)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:704)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
> at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:126)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy146.commit(Unknown Source)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at com.crsoftwareinc.crs.core.domain.aop.advice.UpsertComponentIdMethodInterceptor.invoke(UpsertComponentIdMethodInterceptor.java:201)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke(AbstractTraceInterceptor.java:113)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy440.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:70)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy439.generateReportBySystemCriteria(Unknown Source)
> 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.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)
> at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
> at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
> at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
> at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
> at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
> at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)
> at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:475)
> at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:440)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
> at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:193)
> at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
> at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
> at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> 2007-08-29 08:47:04,125 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Trying again after a pause
> 2007-08-29 08:47:04,421 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] Update worked after retry
> 2007-08-29 08:47:04,421 DEBUG [org.jboss.remoting.ServerInvoker] Thread pool class supplied is not an object 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 lists.jboss.org  Thu Aug 30 12:57:35 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4652) Upgrade Hibernate
 Annotations to 3.3.1 (from 3.3.0)
Message-ID: <18571647.1188493055253.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade Hibernate Annotations to 3.3.1 (from 3.3.0)
---------------------------------------------------

                 Key: JBAS-4652
                 URL: http://jira.jboss.com/jira/browse/JBAS-4652
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Hibernate service
    Affects Versions: JBossAS-5.0.0.Beta2
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-5.0.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 lists.jboss.org  Thu Aug 30 12:57:35 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 30 Aug 2007 12:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1659) Allow for
 multiple defaut roles when a user is created
In-Reply-To: <31676308.1188468513944.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24670667.1188493055832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1659?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1659.
-------------------------------------------

    Resolution: Done

done

> Allow for multiple defaut roles when a user is created
> ------------------------------------------------------
>
>                 Key: JBPORTAL-1659
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1659
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> In the XML configuration for identity portlets, we should be able to specify multiple default 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 lists.jboss.org  Thu Aug 30 12:57:35 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 12:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4563) Hibernate
	Annotations 3.3.0
In-Reply-To: <27808472.1184779067557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14403372.1188493055963.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4563?page=all ]

Dimitris Andreadis updated JBAS-4563:
-------------------------------------

    Summary: Hibernate Annotations 3.3.0  (was: Hibernate Annotations 3.3.1)

Change version in the title.

> Hibernate Annotations 3.3.0
> ---------------------------
>
>                 Key: JBAS-4563
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4563
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 12:59:18 2007
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 30 Aug 2007 12:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1661) Remind password
 feature should be easy to turn off
In-Reply-To: <26688602.1188469100464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17017386.1188493158556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1661?page=all ]

Emanuel Muckenhuber resolved JBPORTAL-1661.
-------------------------------------------

    Resolution: Done

atm you can turn it of by setting the portlet-preference-value 'lostPassword' to false

> Remind password feature should be easy to turn off
> --------------------------------------------------
>
>                 Key: JBPORTAL-1661
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1661
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>            Reporter: Thomas Heute
>         Assigned To: Emanuel Muckenhuber
>             Fix For: 2.8 Final
>
>
> Since the remind password feature requires a configured SMTP server, some users may want to disable it.
> While it would work on Fedora out of the box (and probably other distro too) it could be an issue for Windows 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 lists.jboss.org  Thu Aug 30 13:01:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 13:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3116785.1188493278248.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4564?page=all ]

Dimitris Andreadis updated JBAS-4564:
-------------------------------------

    Summary: Hibernate EntityManager 3.3.1  (was: Hibernate EntityManager 3.3.2)

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 13:01:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 13:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4653) Upgrade Hibernate
 Entity Manager to 3.3.2 (from 3.3.1)
Message-ID: <24362884.1188493278361.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade Hibernate Entity Manager to 3.3.2 (from 3.3.1)
------------------------------------------------------

                 Key: JBAS-4653
                 URL: http://jira.jboss.com/jira/browse/JBAS-4653
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Hibernate service
    Affects Versions:  JBossAS-5.0.0.Beta3
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-5.0.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 lists.jboss.org  Thu Aug 30 13:03:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 30 Aug 2007 13:03:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4652) Upgrade Hibernate
 Annotations to 3.3.1 (from 3.3.0)
In-Reply-To: <18571647.1188493055253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18958515.1188493398299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4652?page=all ]

Dimitris Andreadis updated JBAS-4652:
-------------------------------------

    Affects Version/s:  JBossAS-5.0.0.Beta3
                           (was: JBossAS-5.0.0.Beta2)

> Upgrade Hibernate Annotations to 3.3.1 (from 3.3.0)
> ---------------------------------------------------
>
>                 Key: JBAS-4652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4652
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>    Affects Versions:  JBossAS-5.0.0.Beta3
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-5.0.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 lists.jboss.org  Thu Aug 30 13:10:18 2007
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 30 Aug 2007 13:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-204) Problem
 determing getter for java.lang.Boolean property
Message-ID: <18770961.1188493818213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problem determing getter for java.lang.Boolean property
-------------------------------------------------------

                 Key: JBMICROCONT-204
                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-204
             Project: JBoss MicroContainer
          Issue Type: Bug
          Components: BeanInfo
    Affects Versions:  JBossMC_2_0_0 Beta3
         Environment: org.jboss.test.deployers.managed.test.DeployerManagedDeploymentUnitTestCase.testManagedDeployment
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossMC-2.0.0.Beta4


Trying to create a ManagedProperty for a boolean like:

   @ManagementProperty(name="local-transaction")
   public Boolean isLocalTransactions()
   {
      return localTransactions;
   }

   public void setLocalTransactions(Boolean localTransactions)
   {
      this.localTransactions = localTransactions;
   }

is failing in the AbstractPropertyInfo accessor because there is no getter:

Caused by: java.lang.IllegalArgumentException: Property is not readable: localTransactions for org.jboss.test.deployers.deployer.support.LocalDataSourceMetaData
	at org.jboss.beans.info.plugins.AbstractPropertyInfo.get(AbstractPropertyInfo.java:170)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.getValue(AbstractManagedObjectFactory.java:581)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.java:534)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFactory.java:485)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:166)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.getValue(AbstractManagedObjectFactory.java:622)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.java:534)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFactory.java:485)
	at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:166)
	at org.jboss.test.deployers.deployer.support.MCFDeployer.build(MCFDeployer.java:40)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.build(DeployerWrapper.java:202)
	... 21 more

This works fine if the setter/getter use the primitive boolean type rather than java.lang.Boolean.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 14:33:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 14:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1655) Improve
	"rename" forms
In-Reply-To: <2649337.1188411092173.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29815077.1188498798354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1655?page=all ]

Chris Laprun resolved JBPORTAL-1655.
------------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final
       Resolution: Done

> Improve "rename" forms
> ----------------------
>
>                 Key: JBPORTAL-1655
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1655
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 14:33:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 14:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1655) Improve "rename"
	forms
In-Reply-To: <2649337.1188411092173.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15646708.1188498798458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1655?page=all ]

Chris Laprun updated JBPORTAL-1655:
-----------------------------------

    Component/s: Portal Core Admin
       Priority: Minor  (was: Major)

> Improve "rename" forms
> ----------------------
>
>                 Key: JBPORTAL-1655
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1655
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Thu Aug 30 15:34:19 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 15:34:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-413) Mavenize remoting
	project
Message-ID: <4072643.1188502459174.JavaMail.jira@cloud.prod.atl2.jboss.com>

Mavenize remoting project
-------------------------

                 Key: JBBUILD-413
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-413
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


Remoting project needs to be properly mavenized so that app server builds can use 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 lists.jboss.org  Thu Aug 30 15:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1147) Release 4.0.1
	version
In-Reply-To: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25320087.1188503298655.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1147?page=all ]

Edson Tirelli updated JBRULES-1147:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Release 4.0.1 version
> ---------------------
>
>                 Key: JBRULES-1147
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.2
>
>
> Release 4.0.1 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 lists.jboss.org  Thu Aug 30 15:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1146) No variables are
 shown for Debug points
In-Reply-To: <25789503.1188441198879.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9739660.1188503298830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1146?page=all ]

Edson Tirelli updated JBRULES-1146:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> No variables are shown for Debug points
> ---------------------------------------
>
>                 Key: JBRULES-1146
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1146
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg
>
>
> No variables are showing for break points.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1145) Break points do
 not work at all
In-Reply-To: <10077049.1188435678261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24603452.1188503298999.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1145?page=all ]

Edson Tirelli updated JBRULES-1145:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Break points do not work at all
> -------------------------------
>
>                 Key: JBRULES-1145
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1145
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg
>
>
> Break points do not work 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 lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1144) Toggling
 breakpoint gives an exception
In-Reply-To: <33159382.1188435384455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23616517.1188503299165.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1144?page=all ]

Edson Tirelli updated JBRULES-1144:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Toggling breakpoint gives an exception
> --------------------------------------
>
>                 Key: JBRULES-1144
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1144
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Ahti Kitsik
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Toggling a break point gives an error, this happens in both mvel and java dialect consequences.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1141) context assist no
 longer works for functions in the drl.
In-Reply-To: <17049984.1188270438381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5480440.1188503299357.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1141?page=all ]

Edson Tirelli updated JBRULES-1141:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> context assist no longer works for functions in the drl.
> --------------------------------------------------------
>
>                 Key: JBRULES-1141
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1141
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.2
>
>
> context assist no longer works for functions in the drl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1138) MVEL code
 completion does not work for nested expressions
In-Reply-To: <8066703.1188217998377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9370395.1188503299538.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1138?page=all ]

Edson Tirelli updated JBRULES-1138:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> MVEL code completion does not work for nested expressions
> ---------------------------------------------------------
>
>                 Key: JBRULES-1138
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1138
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.2
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> code completion does not work for parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1132) No code
 completion for 'from' expression statements
In-Reply-To: <28151937.1188060858274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8953197.1188503299718.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1132?page=all ]

Edson Tirelli updated JBRULES-1132:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> No code completion for 'from' expression statements
> ---------------------------------------------------
>
>                 Key: JBRULES-1132
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1132
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Mark Proctor
>         Assigned To: Kris Verlaenen
>             Fix For: 4.0.2
>
>
> If I'm buliding a 'from' statement that is something like from $s.getItems() there is no code completion on that expression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 15:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1124) Code completion
 does not work for 'with' blocks
In-Reply-To: <28780786.1188006918343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5566527.1188503299892.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1124?page=all ]

Edson Tirelli updated JBRULES-1124:
-----------------------------------

    Fix Version/s: 4.0.2
                       (was: 4.0.1)

> Code completion does not work for 'with' blocks
> -----------------------------------------------
>
>                 Key: JBRULES-1124
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1124
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>    Affects Versions:  4.0.0.GA
>            Reporter: Mark Proctor
>         Assigned To: Philippe Ombredanne
>             Fix For: 4.0.2
>
>         Attachments: withCodeCompletion.JPG
>
>
> code completion should work for 'with' blocks. We also use a macro to make 'with' work with the 'modify' keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 15:54:30 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 15:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-413) Mavenize remoting
	project
In-Reply-To: <4072643.1188502459174.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4430305.1188503670356.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-413?page=all ]

Paul Gier reassigned JBBUILD-413:
---------------------------------

    Assignee: Paul Gier

> Mavenize remoting project
> -------------------------
>
>                 Key: JBBUILD-413
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-413
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven
>            Reporter: Paul Gier
>         Assigned To: Paul Gier
>             Fix For: Maven Build - App Server
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Remoting project needs to be properly mavenized so that app server builds can use 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 lists.jboss.org  Thu Aug 30 16:04:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 16:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1147) Release 4.0.1
	version
In-Reply-To: <28389649.1188480558291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6319502.1188504258372.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1147?page=all ]

Edson Tirelli closed JBRULES-1147.
----------------------------------

    Fix Version/s: 4.0.1
                       (was: 4.0.2)
       Resolution: Done

Released.

> Release 4.0.1 version
> ---------------------
>
>                 Key: JBRULES-1147
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1147
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Fernando Meyer
>             Fix For: 4.0.1
>
>
> Release 4.0.1 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 lists.jboss.org  Thu Aug 30 16:06:18 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 30 Aug 2007 16:06:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1285) portal
 testsuite report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8929686.1188504378322.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=comments#action_12374676 ] 
            
Prabhat Jha commented on JBPORTAL-1285:
---------------------------------------

With portal trunk, ant reports fails currently with CNFE for org.apache.tools.ant.taskdefs.optional.TraXLiaison. We need to put ant-trax.jar in tools/lib. 

> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 16:14:18 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 30 Aug 2007 16:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1285) portal
 testsuite report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24375105.1188504858298.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=comments#action_12374679 ] 
            
Prabhat Jha commented on JBPORTAL-1285:
---------------------------------------

After adding the jar, reports still fail with 

reports:
[junitreport] Processing C:\qa\portal-trunk\testsuite\output\reports\TESTS-TestSuites.xml to C:\DOCUME~1\pjha\LOCALS~1\Temp\null1132315364
[junitreport] Loading stylesheet jar:file:/C:/qa/portal-trunk/tools/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Failed to transform using stylesheet jar:file:/C:/qa/portal-trunk/tools/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] Failed to process C:\qa\portal-trunk\testsuite\output\reports\TESTS-TestSuites.xml

BUILD FAILED
C:\qa\portal-trunk\testsuite\build.xml:172: Errors while applying transformations: C:\qa\portal-trunk\testsuite\build.xml:172: class org.apache.tools.ant.taskdefs.optional.TraXLiaison accepts the stylesheet only as a file


Since reports work with ant version that I have, can I go ahead and upload those?? Mine is 1.6.5.



> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 16:34:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Aug 2007 16:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-414) Mavenize security
	project
Message-ID: <22840794.1188506058257.JavaMail.jira@cloud.prod.atl2.jboss.com>

Mavenize security project
-------------------------

                 Key: JBBUILD-414
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-414
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven
            Reporter: Paul Gier
             Fix For: Maven Build - App Server


The pom of the security project should be updated to fit project standards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 17:21:18 2007
From: jira-events at lists.jboss.org (Bhagwath Vadyala (JIRA))
Date: Thu, 30 Aug 2007 17:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1150) Drools 4.0 BRMS
 not working with geronimo-jetty6-jee5-2.0.1
Message-ID: <25850901.1188508878448.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drools 4.0 BRMS not working with geronimo-jetty6-jee5-2.0.1
-----------------------------------------------------------

                 Key: JBRULES-1150
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1150
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
         Environment: geronimo-jetty6-jee5-2.0.1
drools-4.0.1.SNAPSHOT-brms
            Reporter: Bhagwath Vadyala
         Assigned To: Mark Proctor


I am trying to test and see whether Drools 4.0 BRMS works with Geronimo-jetty6-jee5-2.0.1 or not.

Drools BRMS version which I am using is drools-4.0.1.SNAPSHOT-brms.

It deploys fine in Geronimo but when I open the BRMS error message I am getting is HTTP ERROR:404.

Please let me know whether we can make Drools 4.0 work with Geronimo-jetty 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 lists.jboss.org  Thu Aug 30 17:32:18 2007
From: jira-events at lists.jboss.org (Bhagwath Vadyala (JIRA))
Date: Thu, 30 Aug 2007 17:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1150) Drools 4.0 BRMS
 not working with geronimo-jetty6-jee5-2.0.1
In-Reply-To: <25850901.1188508878448.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13863031.1188509538274.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1150?page=all ]

Bhagwath Vadyala updated JBRULES-1150:
--------------------------------------

    Component/s: drools-brms

> Drools 4.0 BRMS not working with geronimo-jetty6-jee5-2.0.1
> -----------------------------------------------------------
>
>                 Key: JBRULES-1150
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1150
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>         Environment: geronimo-jetty6-jee5-2.0.1
> drools-4.0.1.SNAPSHOT-brms
>            Reporter: Bhagwath Vadyala
>         Assigned To: Mark Proctor
>
> I am trying to test and see whether Drools 4.0 BRMS works with Geronimo-jetty6-jee5-2.0.1 or not.
> Drools BRMS version which I am using is drools-4.0.1.SNAPSHOT-brms.
> It deploys fine in Geronimo but when I open the BRMS error message I am getting is HTTP ERROR:404.
> Please let me know whether we can make Drools 4.0 work with Geronimo-jetty 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 lists.jboss.org  Thu Aug 30 17:34:18 2007
From: jira-events at lists.jboss.org (Yuri de Wit (JIRA))
Date: Thu, 30 Aug 2007 17:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1151) Bulding sources
 from root folder fails
Message-ID: <14065664.1188509658255.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bulding sources from root folder fails
--------------------------------------

                 Key: JBRULES-1151
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1151
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions: 4.0.1
            Reporter: Yuri de Wit
         Assigned To: Mark Proctor


Tried to build from sources downloaded from the links provided in the mailing list and got the following (mvn package):

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).


Project ID: unknown

Reason: Could not find the model file 'C:\tools\drools-4.0.1\drools-ant\pom.xml'.


[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Could not find the model file 'C:\tools\drools-4.0.1\drools-ant\pom.xm
l'.
        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
        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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file 'C:\tools\drools-4.0.1\drool
s-ant\pom.xml'.
        at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1274)
        at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.ja
va:414)
        at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192)
        at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
        at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
        at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491)
        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
        ... 11 more
Caused by: java.io.FileNotFoundException: C:\tools\drools-4.0.1\drools-ant\pom.xml (The system cannot find the path spec
ified)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:106)
        at java.io.FileReader.<init>(FileReader.java:55)
        at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1269)
        ... 17 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Aug 30 17:28:45 EDT 2007
[INFO] Final Memory: 1M/3M
[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 lists.jboss.org  Thu Aug 30 17:38:18 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 30 Aug 2007 17:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1285) portal
 testsuite report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4655306.1188509898211.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=comments#action_12374694 ] 
            
Prabhat Jha commented on JBPORTAL-1285:
---------------------------------------

After adding ant-trax.jar with ant 1.7 and removing saxon and xalan jars from tools/lib, I am able to build portal trunk and run reports as well. I think parser or xsl xformer was getting used instead of that of xerces and that's where the problem was.

Is there a dependency on xalan or saxon jars. I am going to run full testsuite before I do a commit but please let me know if you can think of any problem.

These are the jars we need:

ant-junit.jar
ant-launcher.jar
ant-nodeps.jar
ant-trax.jar
ant.jar
bsf.jar
buildmagic-tasks.jar
cargo-core-uberjar-0.8.jar
crimson.jar
explode.jar
jboss-test.jar
jbossbuild.jar
junit.jar
xercesImpl.jar
xml-apis.jar


> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Aug 30 18:05:18 2007
From: jira-events at lists.jboss.org (Steve Miner (JIRA))
Date: Thu, 30 Aug 2007 18:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1152) my unit tests are
 hanging with drools 4.0.1
Message-ID: <1213410.1188511518355.JavaMail.jira@cloud.prod.atl2.jboss.com>

my unit tests are hanging with drools 4.0.1
-------------------------------------------

                 Key: JBRULES-1152
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1152
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.1
         Environment: Java 1.5, Mac OX X 10.4.10, Drools 4.0.1
            Reporter: Steve Miner
         Assigned To: Mark Proctor


Sorry, I don't have very specific information.  Some of my project's unit tests are hanging with drools 4.0.1.  No error, just not completing.  I tried to debug a bit but could not figure it out.  Consider this an early warning until I can gather more info.

Everything worked fine with 4.0 so I went back to 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 lists.jboss.org  Thu Aug 30 18:20:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 18:20:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1654) Add separators
 on object
 pages to allow for better distinction between object and children
 operations
In-Reply-To: <20695198.1188410839568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13397947.1188512418183.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1654?page=all ]

Chris Laprun updated JBPORTAL-1654:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final
             Priority: Minor  (was: Major)

> Add separators on object pages to allow for better distinction between object and children operations
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1654
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1654
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Thu Aug 30 18:31:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 18:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1654) Add separators
 on object
 pages to allow for better distinction between object and children
 operations
In-Reply-To: <20695198.1188410839568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2638832.1188513078176.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1654?page=all ]

Chris Laprun resolved JBPORTAL-1654.
------------------------------------

    Resolution: Done

> Add separators on object pages to allow for better distinction between object and children operations
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1654
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1654
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:10:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:10:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1664)
 CurrentUserPortlet doesn't react to logouts properly
Message-ID: <27651586.1188519018568.JavaMail.jira@cloud.prod.atl2.jboss.com>

CurrentUserPortlet doesn't react to logouts properly
----------------------------------------------------

                 Key: JBPORTAL-1664
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1664
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Samples
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:24:22 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:24:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1665) Highlighting of
 currently selected range in pagination doesn't work properly
Message-ID: <30968748.1188519862544.JavaMail.jira@cloud.prod.atl2.jboss.com>

Highlighting of currently selected range in pagination doesn't work properly
----------------------------------------------------------------------------

                 Key: JBPORTAL-1665
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1665
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core Admin
    Affects Versions: 2.6.1 Final
            Reporter: Chris Laprun
            Priority: Minor
             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:31:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1153)
 Accumulate/Collect can't be used in queries
Message-ID: <9910726.1188520278357.JavaMail.jira@cloud.prod.atl2.jboss.com>

Accumulate/Collect can't be used in queries
-------------------------------------------

                 Key: JBRULES-1153
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1153
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Mark Proctor



query "Count possible cell values"( $row, $col )
    # A superclass or interface can be used to match any derived classes
    $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
                                      count( $a ) )
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 lists.jboss.org  Thu Aug 30 20:31:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-1153)
 Accumulate/Collect can't be used in queries
In-Reply-To: <9910726.1188520278357.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15645015.1188520278550.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1153?page=all ]

Edson Tirelli reassigned JBRULES-1153:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Accumulate/Collect can't be used in queries
> -------------------------------------------
>
>                 Key: JBRULES-1153
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1153
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.2
>
>
> query "Count possible cell values"( $row, $col )
>     # A superclass or interface can be used to match any derived classes
>     $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
>                                       count( $a ) )
> 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 lists.jboss.org  Thu Aug 30 20:31:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1153)
 Accumulate/Collect can't be used in queries
In-Reply-To: <9910726.1188520278357.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12486768.1188520278699.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1153?page=all ]

Edson Tirelli updated JBRULES-1153:
-----------------------------------

        Fix Version/s: 4.0.2
    Affects Version/s: 4.0.1
          Description: 
query "Count possible cell values"( $row, $col )
    # A superclass or interface can be used to match any derived classes
    $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
                                      count( $a ) )
end

  was:

query "Count possible cell values"( $row, $col )
    # A superclass or interface can be used to match any derived classes
    $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
                                      count( $a ) )
end


> Accumulate/Collect can't be used in queries
> -------------------------------------------
>
>                 Key: JBRULES-1153
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1153
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.2
>
>
> query "Count possible cell values"( $row, $col )
>     # A superclass or interface can be used to match any derived classes
>     $count : Number() from accumulate( $a : AbstractCellValue( row == $row, col == $col ),
>                                       count( $a ) )
> 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 lists.jboss.org  Thu Aug 30 20:48:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 30 Aug 2007 20:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1154)
 ClassCastException retrieving query parameters
Message-ID: <11704410.1188521298370.JavaMail.jira@cloud.prod.atl2.jboss.com>

ClassCastException retrieving query parameters
----------------------------------------------

                 Key: JBRULES-1154
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1154
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions: 4.0.1
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.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 lists.jboss.org  Thu Aug 30 20:50:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1588) Portlet
 instance list should
 "scroll" to the appropriate instance when a new instance is inserted in the
 list outside of the initial range
In-Reply-To: <20605356.1184641847020.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32280824.1188521418168.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1588?page=all ]

Chris Laprun resolved JBPORTAL-1588.
------------------------------------

    Resolution: Done

> Portlet instance list should "scroll" to the appropriate instance when a new instance is inserted in the list outside of the initial range
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1588
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1588
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.8 Final, 2.6 Final, 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 20:50:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Thu, 30 Aug 2007 20:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1665) Highlighting of
 currently selected range in pagination doesn't work properly
In-Reply-To: <30968748.1188519862544.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13232536.1188521418243.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1665?page=all ]

Chris Laprun resolved JBPORTAL-1665.
------------------------------------

    Resolution: Done
      Assignee: Chris Laprun

> Highlighting of currently selected range in pagination doesn't work properly
> ----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1665
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1665
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Thu Aug 30 22:13:18 2007
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Thu, 30 Aug 2007 22:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1152) my unit tests
 are hanging with drools 4.0.1
In-Reply-To: <1213410.1188511518355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6193465.1188526398374.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12374708 ] 
            
Michael Neale commented on JBRULES-1152:
----------------------------------------

Waiting for more info (eg some sample code/rules to try out). 

I have access to a mac to try it out if you can provide it. 

> my unit tests are hanging with drools 4.0.1
> -------------------------------------------
>
>                 Key: JBRULES-1152
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1152
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>         Environment: Java 1.5, Mac OX X 10.4.10, Drools 4.0.1
>            Reporter: Steve Miner
>         Assigned To: Mark Proctor
>
> Sorry, I don't have very specific information.  Some of my project's unit tests are hanging with drools 4.0.1.  No error, just not completing.  I tried to debug a bit but could not figure it out.  Consider this an early warning until I can gather more info.
> Everything worked fine with 4.0 so I went back to 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 lists.jboss.org  Thu Aug 30 23:55:19 2007
From: jira-events at lists.jboss.org (Benjamin Madsen (JIRA))
Date: Thu, 30 Aug 2007 23:55:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-288) Fork/Join and child
 token deactivation
Message-ID: <12765489.1188532519077.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-288?page=comments#action_12374712 ] 
            
Benjamin Madsen commented on JBPM-288:
--------------------------------------

This seems to be a fairly old issue, however it is not fixed yet in the core.  Has there been any progress on this issue other than patching it ourselves?  Otherwise, is there a way around the problem that doesn't require patching the codebase?

> 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 lists.jboss.org  Fri Aug 31 03:00:28 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:00:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-763) Release 2.2.1.GA
In-Reply-To: <16838776.1183317717648.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28487731.1188543628320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-763?page=all ]

Ron Sigal closed JBREM-763.
---------------------------

    Resolution: Done

The jboss-remoting.jar file for this release was uploaded to the repository on July 1, 2007.

> Release 2.2.1.GA
> ----------------
>
>                 Key: JBREM-763
>                 URL: http://jira.jboss.com/jira/browse/JBREM-763
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.1.GA
>
>
> This release contains bug fixes for JBREM-747, JBREM-748, JBREM-751, and JBREM-761.  It is intended for inclusion with community JBossAS 4.2.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 lists.jboss.org  Fri Aug 31 03:04:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20125558.1188543858320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal reopened JBREM-779:
-----------------------------

             

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:04:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-779)
 BisocketClientInvoker should
 guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20611056.1188543858443.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal updated JBREM-779:
----------------------------

    Fix Version/s: 2.2.2.GA
                       (was: 2.2.1.SP1)

Fixed in Remoting 2.2.2.GA rather than 2.2.1.SP1.

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP4_CP02, 2.2.2.GA
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:04:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 03:04:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-779) BisocketClientInvoker
 should guard agains scheduling on an expired Timer, part 2
In-Reply-To: <1216709.1184999270904.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30676979.1188543858570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-779?page=all ]

Ron Sigal closed JBREM-779.
---------------------------

    Resolution: Done

> BisocketClientInvoker should guard agains scheduling on an expired Timer, part 2
> --------------------------------------------------------------------------------
>
>                 Key: JBREM-779
>                 URL: http://jira.jboss.com/jira/browse/JBREM-779
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.1.GA, 2.2.0.SP4_CP02
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto)
>
>
> The fix for JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer" involved two places in BisocketClientInvoker where the Timer is created:  the constructor and replaceControlSocket().  The fix in replaceControlSocket(), however, while applied to the remoting_2_x branch, was omitted on the remoting_2_2_0_SP4_CP and remoting_2_2_GA branches.  It should be applied on those latter two branches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:50:53 2007
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 31 Aug 2007 03:50:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-288) Fork/Join and child
 token deactivation
Message-ID: <12176564.1188546653452.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-288?page=comments#action_12374720 ] 
            
Ronald van Kuijk commented on JBPM-288:
---------------------------------------

since it has no target, it can slip of the radar

> 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 lists.jboss.org  Fri Aug 31 03:50:53 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 03:50:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4214563.1188546653575.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374721 ] 
            
Carlo de Wolf commented on JBAS-4564:
-------------------------------------

java.lang.NoClassDefFoundError: org/hibernate/annotations/common/reflection/ReflectionManager
        at org.hibernate.ejb.Ejb3Configuration.<clinit>(Ejb3Configuration.java:105)
        at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:125)


> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 03:50:53 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 03:50:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21544760.1188546653742.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4564?page=all ]

Carlo de Wolf reassigned JBAS-4564:
-----------------------------------

    Assignee: Carlo de Wolf

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 04:18:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 04:18:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
Message-ID: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>

VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
----------------------------------------------------------------------

                 Key: JGRP-586
                 URL: http://jira.jboss.com/jira/browse/JGRP-586
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4.1 SP5, 2.5.1, 2.6


When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 04:40:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 31 Aug 2007 04:40:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19580449.1188549618333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]

Galder Zamarreno resolved JGRP-507.
-----------------------------------

    Fix Version/s: 2.4.1 SP3
                       (was: 2.6)
       Resolution: Done

Change in timer design as part of 2.4.1.SP3 fixed this.

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3 SP1, 2.2.9 SP4, 2.2.7 SP1, 2.4.1, 2.4.1 SP1, 2.4.1 SP2
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.4.1 SP3
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Fri Aug 31 04:57:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 04:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4634) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.0.SP4)
In-Reply-To: <21208408.1188210858201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14915445.1188550638217.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4634?page=comments#action_12374727 ] 
            
Dimitris Andreadis commented on JBAS-4634:
------------------------------------------

Onto 2.2.2.GA-brew.

> Upgrade jboss remoting to v2.2.2.GA (from v2.2.0.SP4)
> -----------------------------------------------------
>
>                 Key: JBAS-4634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4634
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Dimitris Andreadis
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Upgrade to latest remoting 2.2.2.GA when it becomes available.
> Upgraded to jboss remoting 2.2.1.GA in the meantime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:09:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 05:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4578) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.1.GA)
In-Reply-To: <27607751.1185302526035.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1138923.1188551358214.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4578?page=comments#action_12374728 ] 
            
Dimitris Andreadis commented on JBAS-4578:
------------------------------------------

Onto 2.2.2.GA-brew.

> Upgrade jboss remoting to v2.2.2.GA (from v2.2.1.GA)
> ----------------------------------------------------
>
>                 Key: JBAS-4578
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4578
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.2.2.GA
>
>
> There are some remoting fixes that justify a new remoting point release incorporated in JBossAS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:11:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 05:11:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
In-Reply-To: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1278556.1188551478208.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-586?page=comments#action_12374729 ] 
            
Bela Ban commented on JGRP-586:
-------------------------------

This issue does *not* exist in 2.4.x ! The reason it is in 2.5.x and CVS head is that I changed msg.putHeader(GMS.name, ...) to msg.putHeader(name) ! In the second case, name is "VIEW_SYNC", in the first it is "GMS" (which is correct).
So the fix applies only to 2.5 and CVS head (2.6)

> VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
> ----------------------------------------------------------------------
>
>                 Key: JGRP-586
>                 URL: http://jira.jboss.com/jira/browse/JGRP-586
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1, 2.4.1 SP5
>
>
> When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
> However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
> SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:13:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 05:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19748677.1188551598652.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374731 ] 
            
Dimitris Andreadis commented on JBAS-4564:
------------------------------------------

I saw the missing, 

    <componentref name="hibernate-commons-annotations" version="3.0.0.GA"/>    

Thanks Carlo.

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:15:18 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 05:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4634) Upgrade jboss
 remoting to v2.2.2.GA (from v2.2.0.SP4)
In-Reply-To: <21208408.1188210858201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16383218.1188551718227.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4634?page=all ]

Dimitris Andreadis reassigned JBAS-4634:
----------------------------------------

    Assignee: Dimitris Andreadis

> Upgrade jboss remoting to v2.2.2.GA (from v2.2.0.SP4)
> -----------------------------------------------------
>
>                 Key: JBAS-4634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4634
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For:  JBossAS-5.0.0.Beta3
>
>
> Upgrade to latest remoting 2.2.2.GA when it becomes available.
> Upgraded to jboss remoting 2.2.1.GA in the meantime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 04:42:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 31 Aug 2007 04:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-507) CloserThread's
 attempt to
 interrupt TimeScheduler on closure could be end up being ignored
In-Reply-To: <23493172.1178884972324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20586599.1188549738274.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]

Galder Zamarreno updated JGRP-507:
----------------------------------

    Fix Version/s: 2.5

> CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-507
>                 URL: http://jira.jboss.com/jira/browse/JGRP-507
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3 SP1, 2.2.9 SP4, 2.2.7 SP1, 2.4.1, 2.4.1 SP1, 2.4.1 SP2
>            Reporter: Galder Zamarreno
>         Assigned To: Bela Ban
>             Fix For: 2.5, 2.4.1 SP3
>
>
> A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) 
> to never be closed.
> In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status 
> as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems.
> But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
> synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's 
> status as interrupted while the task is running, for example, sending an FD are-you-alive message.
> If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler 
> thread is interrupted while the task is running, the interruption could be caught while sending a message to network:
> TP (UDP and TCP/TCP_NIO's parent):
> TP.down(Event evt)
> ....
> try {
> if(use_outgoing_packet_handler)
> outgoing_queue.put(msg);
> else
> send(msg, dest, multicast);
> }
> catch(QueueClosedException closed_ex) {
> }
> catch(InterruptedException interruptedEx) {
> }
> catch(Throwable e) {
> if(log.isErrorEnabled()) log.error("failed sending message", e);
> } 
> Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If 
> the interruption from CloserThread is caught here, TimeScheduler thread will never finished, 
> leaving the channel blocked and never rejoining the cluster and unable to merge 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 lists.jboss.org  Fri Aug 31 05:19:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 05:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
In-Reply-To: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25834761.1188551958261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-586?page=all ]

Bela Ban updated JGRP-586:
--------------------------

    Fix Version/s:     (was: 2.4.1 SP5)

Removed 2.4.x from fix dest

> VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
> ----------------------------------------------------------------------
>
>                 Key: JGRP-586
>                 URL: http://jira.jboss.com/jira/browse/JGRP-586
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6, 2.5.1
>
>
> When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
> However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
> SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:19:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 05:19:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-586) VIEW_SYNC: GMS
 doesn't accept correct view because of incorrect header
In-Reply-To: <2785200.1188548298337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25637233.1188551958373.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-586?page=all ]

Bela Ban resolved JGRP-586.
---------------------------

    Resolution: Done

Fixed in 2.5 and 2.6

> VIEW_SYNC: GMS doesn't accept correct view because of incorrect header
> ----------------------------------------------------------------------
>
>                 Key: JGRP-586
>                 URL: http://jira.jboss.com/jira/browse/JGRP-586
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5.1, 2.6
>
>
> When VIEW_SYNC gets a view V30 that's greater than its own viewV29, it creates a VIEW message, to be sent up to GMS. GMS will then install that view. 
> However, VIEW_SYNC adds a *VIEW_SYNC* header rather than a *GMS* header, so GMS will simply discard the new (correct) view.
> SOLUTION: VIEW_SYNC must use "GMS" rather than "VIEW_SYNC" in Message.putHeader()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:57:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 31 Aug 2007 05:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1666) When redploying,
 removed preferences in portlet-instances.xml are not deleted
Message-ID: <3657065.1188554238293.JavaMail.jira@cloud.prod.atl2.jboss.com>

When redploying, removed preferences in portlet-instances.xml are not deleted
-----------------------------------------------------------------------------

                 Key: JBPORTAL-1666
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1666
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.1 Final
            Reporter: Thomas Heute
         Assigned To: Julien Viet
             Fix For: 2.6.2 Final, 2.8 Final


with <if-exists>overwrite</if-exists> if someone have a preference in portlet-instances.xml, then remove that preference and redeploy . It won't be reflected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 05:59:18 2007
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Fri, 31 Aug 2007 05:59:18 -0400 (EDT)
Subject: [jboss-jira] 
 [JBoss JIRA] Resolved: (JBPORTAL-1666) When redploying, removed
 preferences in portlet-instances.xml are not deleted
In-Reply-To: <3657065.1188554238293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23838218.1188554358195.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1666?page=all ]

Thomas Heute resolved JBPORTAL-1666.
------------------------------------

    Resolution: Done
      Assignee: Thomas Heute  (was: Julien Viet)

> When redploying, removed preferences in portlet-instances.xml are not deleted
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1666
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1666
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Thomas Heute
>             Fix For: 2.6.2 Final, 2.8 Final
>
>
> with <if-exists>overwrite</if-exists> if someone have a preference in portlet-instances.xml, then remove that preference and redeploy . It won't be reflected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:05:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 06:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4654) JacORB throwing
 spurious UNKNOWN NoSuchMethodException
Message-ID: <27298286.1188554718519.JavaMail.jira@cloud.prod.atl2.jboss.com>

JacORB throwing spurious UNKNOWN NoSuchMethodException
------------------------------------------------------

                 Key: JBAS-4654
                 URL: http://jira.jboss.com/jira/browse/JBAS-4654
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: IIOP service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
         Assigned To: Francisco Reverbel
             Fix For: JBossAS-5.0.0.GA


When a RemoteException contains an exception that isn't mapped to a CorbaException,
JacORB is throwing a spurious NoSuchMethodException.

e.g. the following error thrown by the server in the testsuite:

2007-08-31 11:42:48,113 TRACE [org.jboss.proxy.ejb.EjbObjectCorbaServant.bank-iiop/Account] Exception in EJBObject invocation
javax.management.MBeanException
        at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
        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.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:287)
        at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
        at org.jacorb.poa.RequestProcessor.process(Unknown Source)
        at org.jacorb.poa.RequestProcessor.run(Unknown Source)
Caused by: java.rmi.ServerException: EJBException:; nested exception is: 
        javax.ejb.EJBException: Internal error getting results for field member owner
        at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:365)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
        at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:532)
        at org.jboss.ejb.Container.invoke(Container.java:989)
        at sun.reflect.GeneratedMethodAccessor97.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:157)
        ... 8 more
Caused by: javax.ejb.EJBException: Internal error getting results for field member owner
        at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:498)
        at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:432)
        at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:393)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
        at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
        at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
        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:280)
        at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
        at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
        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:350)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:238)
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:105)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
        ... 15 more
Caused by: java.sql.SQLException: Got a org.omg.stub.javax.ejb._EJBObject_Stub[cl=org.jboss.mx.loading.UnifiedClassLoader3 at ff45de{ url=vfsfile:/home/ejort/jboss-head/b

Results in the following on the client:

"CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExcept
ion: CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
        at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
        at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
        at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
        at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
        at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source)
        at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
        at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
        at org.jacorb.orb.Delegate.invoke(Unknown Source)
        at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)
        ... 23 more
Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.&lt;init&gt;(java.lang.String, int, org.omg.CORBA.CompletionStatus)
        at java.lang.Class.getConstructor0(Class.java:2678)
        at java.lang.Class.getConstructor(Class.java:1629)
        ... 29 more

The NoSuchMethodException is obviously not the cause.
It comes from jacorb assuming that all Corba SystemExceptions have a constructor of a certain signature
(something that is not true for UnknownException).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:07:25 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 06:07:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4654) JacORB throwing
 spurious UNKNOWN NoSuchMethodException
In-Reply-To: <27298286.1188554718519.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13816685.1188554845875.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4654?page=all ]

Adrian Brock updated JBAS-4654:
-------------------------------

    Attachment: SystemExceptionHelper.java

Attached is an updated version of JacORB's SystemExceptionHelper
that at least removes the spurious NoSuchMethodException.

It basically adds:

        catch (NoSuchMethodException e)

        {
            return (org.omg.CORBA.SystemException) new org.omg.CORBA.UNKNOWN(className + ": " + message);
        }

And produces output like the following.

CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException:   vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExce
ption: CORBA UNKNOWN 0 No; nested exception is: 
        org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException:   vmcid: 0x0  minor code: 0  completed: No
        at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
        at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
        at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
        at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
        at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException:   vmcid: 0x0  minor code: 0  completed: No
        at org.jacorb.orb.SystemExceptionHelper.read(SystemExceptionHelper.java:230)
        at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
        at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
        at org.jacorb.orb.Delegate.invoke(Unknown Source)
        at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
        at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)


> JacORB throwing spurious UNKNOWN NoSuchMethodException
> ------------------------------------------------------
>
>                 Key: JBAS-4654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4654
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-5.0.0.GA
>
>         Attachments: SystemExceptionHelper.java
>
>
> When a RemoteException contains an exception that isn't mapped to a CorbaException,
> JacORB is throwing a spurious NoSuchMethodException.
> e.g. the following error thrown by the server in the testsuite:
> 2007-08-31 11:42:48,113 TRACE [org.jboss.proxy.ejb.EjbObjectCorbaServant.bank-iiop/Account] Exception in EJBObject invocation
> javax.management.MBeanException
>         at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
>         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.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:287)
>         at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.process(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.run(Unknown Source)
> Caused by: java.rmi.ServerException: EJBException:; nested exception is: 
>         javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:365)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:532)
>         at org.jboss.ejb.Container.invoke(Container.java:989)
>         at sun.reflect.GeneratedMethodAccessor97.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:157)
>         ... 8 more
> Caused by: javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:498)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:432)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:393)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
>         at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
>         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:280)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
>         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:350)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:238)
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:105)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         ... 15 more
> Caused by: java.sql.SQLException: Got a org.omg.stub.javax.ejb._EJBObject_Stub[cl=org.jboss.mx.loading.UnifiedClassLoader3 at ff45de{ url=vfsfile:/home/ejort/jboss-head/b
> Results in the following on the client:
> "CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExcept
> ion: CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
>         at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
>         at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
>         at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>         at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source)
>         at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke(Unknown Source)
>         at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)
>         ... 23 more
> Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.&lt;init&gt;(java.lang.String, int, org.omg.CORBA.CompletionStatus)
>         at java.lang.Class.getConstructor0(Class.java:2678)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         ... 29 more
> The NoSuchMethodException is obviously not the cause.
> It comes from jacorb assuming that all Corba SystemExceptions have a constructor of a certain signature
> (something that is not true for UnknownException).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:09:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 06:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4654) JacORB throwing
 spurious UNKNOWN NoSuchMethodException
In-Reply-To: <27298286.1188554718519.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18983320.1188554958397.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4654?page=comments#action_12374737 ] 
            
Adrian Brock commented on JBAS-4654:
------------------------------------

On a related issue, it would nice if there was someway to pass the "message" back to the client
for the UnknownExceptions?

i.e. the
java.rmi.ServerException: EJBException:; nested exception is:  javax.ejb.EJBException: Internal error getting results for field member owner

etc.

> JacORB throwing spurious UNKNOWN NoSuchMethodException
> ------------------------------------------------------
>
>                 Key: JBAS-4654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4654
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-5.0.0.GA
>
>         Attachments: SystemExceptionHelper.java
>
>
> When a RemoteException contains an exception that isn't mapped to a CorbaException,
> JacORB is throwing a spurious NoSuchMethodException.
> e.g. the following error thrown by the server in the testsuite:
> 2007-08-31 11:42:48,113 TRACE [org.jboss.proxy.ejb.EjbObjectCorbaServant.bank-iiop/Account] Exception in EJBObject invocation
> javax.management.MBeanException
>         at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
>         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.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:287)
>         at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.process(Unknown Source)
>         at org.jacorb.poa.RequestProcessor.run(Unknown Source)
> Caused by: java.rmi.ServerException: EJBException:; nested exception is: 
>         javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:365)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:209)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:532)
>         at org.jboss.ejb.Container.invoke(Container.java:989)
>         at sun.reflect.GeneratedMethodAccessor97.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:157)
>         ... 8 more
> Caused by: javax.ejb.EJBException: Internal error getting results for field member owner
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:498)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:432)
>         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:393)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:207)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:88)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:646)
>         at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:628)
>         at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:406)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
>         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:280)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
>         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:350)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:238)
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:105)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         ... 15 more
> Caused by: java.sql.SQLException: Got a org.omg.stub.javax.ejb._EJBObject_Stub[cl=org.jboss.mx.loading.UnifiedClassLoader3 at ff45de{ url=vfsfile:/home/ejort/jboss-head/b
> Results in the following on the client:
> "CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No" type="java.rmi.RemoteException">java.rmi.RemoteExcept
> ion: CORBA UNKNOWN 0 No; nested exception is: 
>         org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:282)
>         at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:148)
>         at org.jboss.test.bankiiop.interfaces._Account_Stub.getPrimaryKey(Unknown Source)
>         at org.jboss.test.bankiiop.test.BankStressTestCase.testTeller(BankStressTestCase.java:88)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>         at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.omg.CORBA.UNKNOWN: org.omg.CORBA.portable.UnknownException  vmcid: 0x0  minor code: 0  completed: No
>         at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source)
>         at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke_internal(Unknown Source)
>         at org.jacorb.orb.Delegate.invoke(Unknown Source)
>         at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
>         at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:123)
>         ... 23 more
> Caused by: java.lang.NoSuchMethodException: org.omg.CORBA.portable.UnknownException.&lt;init&gt;(java.lang.String, int, org.omg.CORBA.CompletionStatus)
>         at java.lang.Class.getConstructor0(Class.java:2678)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         ... 29 more
> The NoSuchMethodException is obviously not the cause.
> It comes from jacorb assuming that all Corba SystemExceptions have a constructor of a certain signature
> (something that is not true for UnknownException).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:30:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:30:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
Message-ID: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>

Problems for connecting a Weblogic 10 Portal WSRP Producer
----------------------------------------------------------

                 Key: JBPORTAL-1667
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.6.1 Final, 2.6 Final
         Environment: Microsoft Windows 2000
Sun JDK 1.5.06
JBoss Portal 2.6.1 Final
JBoss Portal 2.6 Final
            Reporter: Mehmet Salgar
         Assigned To: Chris Laprun


I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 

'ERROR [CallImpl] Call invocation failed with SOAPFaultException
javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
        java.lang.NumberFormatException: null'

I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.

When I try to connect from WSRP Admin portlet to the WSDL URL I am getting this exception.

Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.

Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.

I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.

The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.

Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.

I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:32:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17069802.1188556338347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Mehmet Salgar updated JBPORTAL-1667:
------------------------------------

    Description: 
I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 

'ERROR [CallImpl] Call invocation failed with SOAPFaultException
javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
        java.lang.NumberFormatException: null'

I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.

When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.

Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.

Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.

I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.

The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.

Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.

I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

  was:
I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 

'ERROR [CallImpl] Call invocation failed with SOAPFaultException
javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
        java.lang.NumberFormatException: null'

I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.

When I try to connect from WSRP Admin portlet to the WSDL URL I am getting this exception.

Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.

Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.

I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.

The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.

Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.

I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.


> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>         Attachments: myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:32:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9820557.1188556338546.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Mehmet Salgar updated JBPORTAL-1667:
------------------------------------

    Attachment: myPortalEAR.ear

> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>         Attachments: myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:34:18 2007
From: jira-events at lists.jboss.org (Mehmet Salgar (JIRA))
Date: Fri, 31 Aug 2007 06:34:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9973629.1188556458266.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Mehmet Salgar updated JBPORTAL-1667:
------------------------------------

    Attachment: fullstacktrace.txt

> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>         Attachments: fullstacktrace.txt, myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 06:40:25 2007
From: jira-events at lists.jboss.org (Mircea Markus (JIRA))
Date: Fri, 31 Aug 2007 06:40:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1154) Introduce ability
 to mark
 nodes as resident- i.e., they never get considered for eviction
In-Reply-To: <19979184.1185539627066.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5746725.1188556825312.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-1154?page=all ]

Mircea Markus updated JBCACHE-1154:
-----------------------------------

    Summary: Introduce ability to mark nodes as resident- i.e., they never get considered for eviction  (was: Introduce ability to mark nodes as immortal - i.e., they never get considered for eviction)

resident is a name that fits better than immortal - after all the nodes can be removed, but are not counted by eviction policies

> Introduce ability to mark nodes as resident- i.e., they never get considered for eviction
> -----------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 07:21:18 2007
From: jira-events at lists.jboss.org (Thomas Hehl (JIRA))
Date: Fri, 31 Aug 2007 07:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1155) In Decision Table
 actions, cannot reference variables that were not referenced in LHS
Message-ID: <1012264.1188559278297.JavaMail.jira@cloud.prod.atl2.jboss.com>

In Decision Table actions, cannot reference variables that were not referenced in LHS
-------------------------------------------------------------------------------------

                 Key: JBRULES-1155
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1155
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
    Affects Versions: 4.0.1
         Environment: Windows
            Reporter: Thomas Hehl
         Assigned To: Mark Proctor
            Priority: Minor


If I use a decision table to build rules for my application, there doesn't appear to be a way to store an answer on a variable that wasn't referenced in the LHS of the rule. This is because the reference to the object that must be built can only be defined in the LHS.

I would like to be able to directly reference these "catcher" objects from the action to store the result even if they were not needed as part of the LHS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:01:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
Message-ID: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>

Suppling a RemoteHome or LocalHome is not registered
----------------------------------------------------

                 Key: EJBTHREE-1041
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:01:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
In-Reply-To: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17142915.1188561678507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1041?page=all ]

Carlo de Wolf reassigned EJBTHREE-1041:
---------------------------------------

    Assignee: Carlo de Wolf

> Suppling a RemoteHome or LocalHome is not registered
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1041
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:03:34 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:03:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
In-Reply-To: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5765254.1188561814161.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1041?page=all ]

Carlo de Wolf updated EJBTHREE-1041:
------------------------------------

    Fix Version/s: EJB 3.0 RC11 - FD
      Description: When a bean declares a RemoteHome or LocalHome the interface is not registered in MC as a supply.
         Priority: Critical  (was: Major)

> Suppling a RemoteHome or LocalHome is not registered
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1041
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - FD
>
>
> When a bean declares a RemoteHome or LocalHome the interface is not registered in MC as a supply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:13:18 2007
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Aug 2007 08:13:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1041) Suppling a
 RemoteHome or LocalHome is not registered
In-Reply-To: <24989384.1188561678285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26122075.1188562398219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1041?page=all ]

Carlo de Wolf resolved EJBTHREE-1041.
-------------------------------------

    Resolution: Done

> Suppling a RemoteHome or LocalHome is not registered
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1041
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1041
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC11 - FD
>
>
> When a bean declares a RemoteHome or LocalHome the interface is not registered in MC as a supply.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:41:22 2007
From: jira-events at lists.jboss.org (Mircea Markus (JIRA))
Date: Fri, 31 Aug 2007 08:41:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1154) Introduce
 ability to mark
 nodes as resident- i.e., they never get considered for eviction
In-Reply-To: <19979184.1185539627066.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18787125.1188564082847.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1154?page=comments#action_12374743 ] 
            
Mircea Markus commented on JBCACHE-1154:
----------------------------------------

created topic on design forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=207
Steve - any feedback extremely welcomed!


> Introduce ability to mark nodes as resident- i.e., they never get considered for eviction
> -----------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1154
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1154
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>            Reporter: Manik Surtani
>         Assigned To: Mircea Markus
>             Fix For: 2.1.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:48:19 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 08:48:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
In-Reply-To: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32775322.1188564499104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1149?page=all ]

Edson Tirelli reopened JBRULES-1149:
------------------------------------

             
Reopening. Problem still persists.

> Parser is only saving last CE for prefixed AND/OR 
> --------------------------------------------------
>
>                 Key: JBRULES-1149
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Reported by user:
> Hi,
> I have a problem with this execution :
> rule "Your First Rule"
> when
>  (or
>  not Venue()
>  (and v:Venue()
>        l:ListeSousVenue()
>        p:Param()))
> then
>  System.out.println("OK - 1");
> end
> rule "Your Second Rule"
> when
>  (or
>  not Venue()
>  (and p:Param()
>        l:ListeSousVenue()
>        v:Venue()))
> then
>    System.out.println("OK - 2");
> end
> In my WM, I have a Param and a ListeSousVenue but no Venue
> But after execution, I have just this result :
> "OK - 1"
> Why the second rule doesn't execute ?
> Thanks,
> Vdelbart

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:58:29 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1149) Parser is only
 saving last CE for prefixed AND/OR
In-Reply-To: <22597974.1188490938365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19880252.1188565109524.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1149?page=all ]

Edson Tirelli closed JBRULES-1149.
----------------------------------

    Resolution: Done

It was fixed. Problem is in file logger.

> Parser is only saving last CE for prefixed AND/OR 
> --------------------------------------------------
>
>                 Key: JBRULES-1149
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1149
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions:  4.0.0.GA
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.1
>
>
> Reported by user:
> Hi,
> I have a problem with this execution :
> rule "Your First Rule"
> when
>  (or
>  not Venue()
>  (and v:Venue()
>        l:ListeSousVenue()
>        p:Param()))
> then
>  System.out.println("OK - 1");
> end
> rule "Your Second Rule"
> when
>  (or
>  not Venue()
>  (and p:Param()
>        l:ListeSousVenue()
>        v:Venue()))
> then
>    System.out.println("OK - 2");
> end
> In my WM, I have a Param and a ListeSousVenue but no Venue
> But after execution, I have just this result :
> "OK - 1"
> Why the second rule doesn't execute ?
> Thanks,
> Vdelbart

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 08:58:29 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1156)
 WorkingMemoryFileLogger is
 raising NPE for rules containing unbalanced OR CEs
Message-ID: <22151416.1188565109632.JavaMail.jira@cloud.prod.atl2.jboss.com>

WorkingMemoryFileLogger is raising NPE for rules containing unbalanced OR CEs
-----------------------------------------------------------------------------

                 Key: JBRULES-1156
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1156
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions: 4.0.1
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 4.0.2


Apply WorkingMemoryFileLogger for rules like the following and it will raise the NPE:

rule "Your First Rule"
	#include attributes such as "salience" here...
	when
		(or
		 not Venue()
		(and v:Venue()
		  l:ListeSousVenue()
		  p:Param()))
	then 
		#actions
		System.out.println("OK - 1");
end
rule "Your Second Rule"
	#include attributes such as "salience" here...
	when
		(or
		 not Venue()
		(and p:Param()
		     l:ListeSousVenue()
		     v:Venue()))
	then 
		#actions
		System.out.println("OK - 2");
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 lists.jboss.org  Fri Aug 31 09:02:18 2007
From: jira-events at lists.jboss.org (Markus Fromme (JIRA))
Date: Fri, 31 Aug 2007 09:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-1157) threads using one
 ruleset throws exception
Message-ID: <23447978.1188565338418.JavaMail.jira@cloud.prod.atl2.jboss.com>

threads using one ruleset throws exception
------------------------------------------

                 Key: JBRULES-1157
                 URL: http://jira.jboss.com/jira/browse/JBRULES-1157
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.1
         Environment: Windows XP, Eclipse 3.2
            Reporter: Markus Fromme
         Assigned To: Mark Proctor
            Priority: Critical


one ruleset for two threads using their own statefulsession and data results in this error:

Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:08:18 2007
From: jira-events at lists.jboss.org (Markus Fromme (JIRA))
Date: Fri, 31 Aug 2007 09:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1157) threads using one
 ruleset throws exception
In-Reply-To: <23447978.1188565338418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25917263.1188565698581.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1157?page=all ]

Markus Fromme updated JBRULES-1157:
-----------------------------------

    Description: 
one ruleset for two threads using their own statefulsession and data results in this error:

Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)
Exception in thread "Thread-0" java.lang.NullPointerException
	at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:220)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:158)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)


  was:
one ruleset for two threads using their own statefulsession and data results in this error:

Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
	at eu.cewe.drools.Client.run(Client.java:22)


> threads using one ruleset throws exception
> ------------------------------------------
>
>                 Key: JBRULES-1157
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1157
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Markus Fromme
>         Assigned To: Mark Proctor
>            Priority: Critical
>
> one ruleset for two threads using their own statefulsession and data results in this error:
> Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 17
> 	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:257)
> 	at org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:262)
> 	at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:130)
> 	at org.drools.common.AbstractRuleBase.getWorkingMemories(AbstractRuleBase.java:605)
> 	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:157)
> 	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
> 	at eu.cewe.drools.Client.run(Client.java:22)
> Exception in thread "Thread-0" java.lang.NullPointerException
> 	at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:220)
> 	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:158)
> 	at org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:418)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:153)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:164)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1260)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:826)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:627)
> 	at eu.cewe.drools.Client.run(Client.java:22)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:08:18 2007
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Aug 2007 09:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-585) FD_SOCK: make
 fetching of cache asynchronous
In-Reply-To: <29535831.1188476178345.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6421739.1188565698697.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-585?page=all ]

Bela Ban resolved JGRP-585.
---------------------------

    Resolution: Done

Tested with JGroups/doc/tests/ManualTests.txt, passed

> FD_SOCK: make fetching of cache asynchronous
> --------------------------------------------
>
>                 Key: JGRP-585
>                 URL: http://jira.jboss.com/jira/browse/JGRP-585
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> FD_SOCK fetches the cache *synchronously* on down(VIEW_CHANGE). This blocks until the cache has been received, blocking down() and therefore other down calls. This could for example block a JOIN_RSP to a new joiner, causing the JOIN_REQ to fail.
> [Vladimir]
> Trying to dig into the trenches in order to understand why exactly is ConcurrentStartupTest failing if we switch up and down view sending in GMS#installView! I noticed that FD_SOCK in down for VIEW_CHANGE event does a very unusual thing: synchronous mcast invocation and it does it repeatedly until succeeds in getting cache contents or timeouts. But it does not look like it is 100% necessary to do this? Can't we abstract getting cache contents into a task that is run on a timer until we get a result? So we effectively we make getting cache contents asynchronous that does not potentially block view installation for quite a while because as it is now - this is what is happening.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:08:18 2007
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 31 Aug 2007 09:08:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-1154) ClassCastException
 retrieving query parameters
In-Reply-To: <11704410.1188521298370.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27266388.1188565698826.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-1154?page=all ]

Edson Tirelli closed JBRULES-1154.
----------------------------------

    Resolution: Done

Fixed

> ClassCastException retrieving query parameters
> ----------------------------------------------
>
>                 Key: JBRULES-1154
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1154
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions: 4.0.1
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 4.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 lists.jboss.org  Fri Aug 31 09:26:18 2007
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Fri, 31 Aug 2007 09:26:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9058949.1188566778268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374756 ] 
            
Emmanuel Bernard commented on JBAS-4564:
----------------------------------------

Yes hibernate-commons-annotations is required.
Another problem may arise. Hibernate Validator (the component) is now separate from hibernate-annotations
Do we consider it part of the JBoss AS distro, or is it safe to not include it (ie let the user add it if needed)?

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 09:28:18 2007
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Fri, 31 Aug 2007 09:28:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-4455) LoadBalancePolicy
 that tries to pin all requests associated with a tx to one server
In-Reply-To: <14717863.1180632608477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26062394.1188566898326.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4455?page=all ]

Galder Zamarreno updated JBAS-4455:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117013

> LoadBalancePolicy that tries to pin all requests associated with a tx to one server
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-4455
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4455
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> The HA proxies don't allow failover once a tx has reached a server.  This can lead to this kind of situation:
> EJB A deployed on nodes 1 and 2.
> EJB B deployed on nodes 1 and 2.
> 1) Start tx, invoke on A.1.
> 2) Lookup B.
> 3) Invoke on B. LB policy picks B.2
> 4) Node 2 is dead for some reason so call fails.
> 5) Can't fail over because tx context won't allow a failover after a call has reached a server.
> But, B.1 is fine and is running on the only node the tx has invoked on. :(
> Approach to improving this.  This is based on JRMPInovkerProxyHA methods, but the idea is generic:
> In invocationHasReachedAServer, instead of storing null as the value, you store the target (key is the tx).
> In invoke, if there's a tx, you add that target (if there is one) to the invocation as transient metadata 
> The LB policy gets passed the invocation as an arg when it chooses a target (this is already in the API)
> LB policy checks for the metadata. If there, and that target is in its target list, return that target

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:05:52 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 10:05:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1668) A user with
 "Administrator"
 privileges is not able to create resources at the root level of the CMS
 repo
Message-ID: <22525764.1188569152087.JavaMail.jira@cloud.prod.atl2.jboss.com>

A user with "Administrator" privileges is not able to create resources at the root level of the CMS repo
--------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1668
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1668
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.6.1 Final, 2.6 Final, 2.6 CR3, 2.6.CR1, 2.6.CR2, 2.6.Beta1, 2.6.Alpha2, 2.6.Alpha1
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 2.6.2 Final


How to reproduce-

Assign a Portal user to Administrator group. Login as this user, and try to create a Folder at "/" path of the CMS repo.

You get an Access Denied 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 lists.jboss.org  Fri Aug 31 10:09:25 2007
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 31 Aug 2007 10:09:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4564) Hibernate
	EntityManager 3.3.1
In-Reply-To: <24168113.1184779067672.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23527675.1188569365946.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4564?page=comments#action_12374767 ] 
            
Dimitris Andreadis commented on JBAS-4564:
------------------------------------------

I don't think it would make harm if we include it, as it was implicitly included before.

> Hibernate EntityManager 3.3.1
> -----------------------------
>
>                 Key: JBAS-4564
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4564
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Hibernate service
>            Reporter: Emmanuel Bernard
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For:  JBossAS-5.0.0.Beta3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:21:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Aug 2007 10:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1063) MessageID
 changes when the message is transfered over the cluster.
Message-ID: <22046415.1188570078656.JavaMail.jira@cloud.prod.atl2.jboss.com>

MessageID changes when the message is transfered over the cluster.
------------------------------------------------------------------

                 Key: JBMESSAGING-1063
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1063
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.0.CR2
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.4.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:45:19 2007
From: jira-events at lists.jboss.org (Matthew Sandoz (JIRA))
Date: Fri, 31 Aug 2007 10:45:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-14) Lay out Algorithm
In-Reply-To: <763449.1168949213846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12526320.1188571519076.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/GPD-14?page=comments#action_12374783 ] 
            
Matthew Sandoz commented on GPD-14:
-----------------------------------

I'm looking at creating an implementation of this feature that pulls the graph structure into another package that does layouts and then generating move commands. Is that a viable approach or is there a specific set of algorithms you'd need to use? I would then simply include a button or menu item to apply the layout(s). I may have some time over the next month or so to put it together.


> Lay out Algorithm
> -----------------
>
>                 Key: GPD-14
>                 URL: http://jira.jboss.com/jira/browse/GPD-14
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Minor
>
> Integrate a layout algorithm that is used when users add nodes to the xml directly to lay out the newly created components in an orderly fashion on the graphical canvas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:49:29 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 10:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3589940.1188571769767.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=comments#action_12374784 ] 
            
Chris Laprun commented on JBPORTAL-1667:
----------------------------------------

"The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem. Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves."

Why do you assume that it's JBoss Portal's fault? I could make modifications to both our consumer and producer in such a way that it would not be conform to the specification and yet work perfectly well with each other but break with every other products out there... The fact that WLP works with itself is not conclusive evidence that its implementation is correct.

That said I will look into the problem. Could you please attach the ServiceDescription sent by WLP 10?




> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: fullstacktrace.txt, myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:49:29 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 10:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1667) Problems for
 connecting a Weblogic 10 Portal WSRP Producer
In-Reply-To: <12944023.1188556218473.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25908110.1188571769907.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1667?page=all ]

Chris Laprun updated JBPORTAL-1667:
-----------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final

> Problems for connecting a Weblogic 10 Portal WSRP Producer
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6.1 Final, 2.6 Final
>         Environment: Microsoft Windows 2000
> Sun JDK 1.5.06
> JBoss Portal 2.6.1 Final
> JBoss Portal 2.6 Final
>            Reporter: Mehmet Salgar
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 Final
>
>         Attachments: fullstacktrace.txt, myPortalEAR.ear
>
>
> I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 
> 'ERROR [CallImpl] Call invocation failed with SOAPFaultException
> javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is:
>         java.lang.NumberFormatException: null'
> I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet.
> When I try to connect from WSRP Admin portlet to the WSDL URL and refresh I am getting this exception.
> Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem.
> Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at  WLP 10, but we are getting this exception.
> I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem.
> The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem.
> Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves.
> I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 10:57:18 2007
From: jira-events at lists.jboss.org (Fernando Nasser (JIRA))
Date: Fri, 31 Aug 2007 10:57:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4148) Replace Gjt code
 used in the ejb 2.x validation phase
In-Reply-To: <23704302.1172165075447.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6646524.1188572238321.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-4148?page=all ]

Fernando Nasser reassigned JBAS-4148:
-------------------------------------

    Assignee: Juha Lindfors

Can you help us with this?

> Replace Gjt code used in the ejb 2.x validation phase
> -----------------------------------------------------
>
>                 Key: JBAS-4148
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4148
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Fernando Nasser
>         Assigned To: Juha Lindfors
>             Fix For: JBossAS-4.2.2.GA
>
>
> The JBossAS thirdpart-build.xml grabs a
> <componentref name="gjt-jpl-util" version="1.0"/>
> from repository.jboss.com
> However, the Gjt project has never released a 1.0 version, only a 0.6 version for the Linffors utils and the jpl_util_0_6 is the only tag in their CVS.
> So, what is the meaning for version 1.0?  The CVS tip?
> Also, what is marked as gjt-jpl-util also contains gjt-jpl-pattern, and the latest CVS tag for that is:
> jpl-pattern_0_3_b    (0.3 beta perhaps)
> Besides, there is a warning in the pattern source directory:
> "Untagged files may be (and probably are) in an unstable state and might not
> compile. If you want something that works, checkout with tags. You have been
> warned. :)  -- Juha" 
> Here, for the record, is Scott's opinion:
> Scott M Stark wrote:
> > This is some ancient code used only in the ejb 2.x validation phase. It
> > has not been touched in something like 5 years. Either we need to
> > replace it or pull together some code that makes up a usable 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 lists.jboss.org  Fri Aug 31 11:22:34 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 11:22:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-4655) HandleImplIIOP not
 retrieving EJBObject correctly
Message-ID: <7109367.1188573754351.JavaMail.jira@cloud.prod.atl2.jboss.com>

HandleImplIIOP not retrieving EJBObject correctly
-------------------------------------------------

                 Key: JBAS-4655
                 URL: http://jira.jboss.com/jira/browse/JBAS-4655
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: IIOP service
    Affects Versions: JBossAS-4.2.1.GA
            Reporter: Adrian Brock
             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA


The IIOP tests in JBoss Head are failing because the
HandleImplIIOP.getEJBObject()
is returning a stub only for EJBObject and not for the business interface.

The test should also be failing in jboss-4.2 but the test isn't failing because
it is using commit option A and thus not reloading from the database.

I'm going to change the bankiiop stress test in jboss-4.2 to use "instance per transaction" to show the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:32:18 2007
From: jira-events at lists.jboss.org (Adrian Brock (JIRA))
Date: Fri, 31 Aug 2007 11:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4655) HandleImplIIOP not
 retrieving EJBObject correctly
In-Reply-To: <7109367.1188573754351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20996079.1188574338202.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-4655?page=comments#action_12374797 ] 
            
Adrian Brock commented on JBAS-4655:
------------------------------------

The reason why the test is failing is because HandleImplIIOP is doing

PortableRemoteObject.narrow(CorbaORB.getInstance().string_to_object(ior), EJBObject.class);

PortableRemoteObject.narrow()
tests whether the object implements the class
if it does not, it "generates" the stub from the passed class.

In jacorb's case, string.to_object(ior) returns an org.jacorb.orb.Reference

> HandleImplIIOP not retrieving EJBObject correctly
> -------------------------------------------------
>
>                 Key: JBAS-4655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4655
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.2.1.GA
>            Reporter: Adrian Brock
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> The IIOP tests in JBoss Head are failing because the
> HandleImplIIOP.getEJBObject()
> is returning a stub only for EJBObject and not for the business interface.
> The test should also be failing in jboss-4.2 but the test isn't failing because
> it is using commit option A and thus not reloading from the database.
> I'm going to change the bankiiop stress test in jboss-4.2 to use "instance per transaction" to show the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:49:18 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Aug 2007 11:49:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1063) MessageID
 changes when the message is transfered over the cluster.
In-Reply-To: <22046415.1188570078656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11625662.1188575358797.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1063?page=all ]

Clebert Suconic updated JBMESSAGING-1063:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117536

> MessageID changes when the message is transfered over the cluster.
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1063
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1063
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:49:19 2007
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Aug 2007 11:49:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1063) MessageID
 changes when the message is transfered over the cluster.
In-Reply-To: <22046415.1188570078656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32285581.1188575359111.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1063?page=all ]

Clebert Suconic closed JBMESSAGING-1063.
----------------------------------------

    Resolution: Done

> MessageID changes when the message is transfered over the cluster.
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1063
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1063
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.4.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 11:53:18 2007
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Fri, 31 Aug 2007 11:53:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-587) Lightweight FLUSH for
 state transfer
Message-ID: <33510599.1188575598551.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lightweight FLUSH for state transfer
------------------------------------

                 Key: JGRP-587
                 URL: http://jira.jboss.com/jira/browse/JGRP-587
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.7


We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:09:18 2007
From: jira-events at lists.jboss.org (Michael Small (JIRA))
Date: Fri, 31 Aug 2007 12:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJMX-108) Provide JAAS
 credentials in
 org.jboss.ant.JMX task so that calls can be made to security protected
 MBeans.
Message-ID: <3443802.1188576558213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide JAAS credentials in org.jboss.ant.JMX task so that calls can be made to security protected MBeans.
----------------------------------------------------------------------------------------------------------

                 Key: JBJMX-108
                 URL: http://jira.jboss.com/jira/browse/JBJMX-108
             Project: JBoss JMX
          Issue Type: Feature Request
            Reporter: Michael Small


I have MBeans (using the @Security and @Management annotations) that are associated with a security domain.  It would great if the JBoss JMX Ant Task was enhanced to accept a username and password for JAAS security.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:11:19 2007
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Fri, 31 Aug 2007 12:11:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-1285) portal testsuite
 report generation issue with ant that ships with portal
In-Reply-To: <29755563.1171991320215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13314466.1188576679250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1285?page=all ]

Prabhat Jha closed JBPORTAL-1285.
---------------------------------

    Resolution: Done

I just did a complete build and ran the whole testsuite with ant in tools/lib. trunk/buid/build.bat and trunk/testsuiste/build.bat tests/reports

> portal testsuite report generation issue with ant that ships with portal
> ------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1285
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha2
>            Reporter: Prabhat Jha
>         Assigned To: Prabhat Jha
>
> When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl"
> It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed.
> See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:23:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 31 Aug 2007 12:23:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-415) Add a feature to
 dependency plugin to find conflicting versions
Message-ID: <31981849.1188577398230.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a feature to dependency plugin to find conflicting versions
---------------------------------------------------------------

                 Key: JBBUILD-415
                 URL: http://jira.jboss.com/jira/browse/JBBUILD-415
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: Maven
    Affects Versions: Maven Build - Maint 2007
            Reporter: Paul Gier


Add a feature to the maven dependency plugin that finds if a dependency tree contains two different versions of the same artifact.
This could be an additional section in the results of the analyze goal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 12:25:18 2007
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 31 Aug 2007 12:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-415) Add a feature to
 dependency plugin to find conflicting versions
In-Reply-To: <31981849.1188577398230.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1293297.1188577518254.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBBUILD-415?page=all ]

Paul Gier updated JBBUILD-415:
------------------------------

        Fix Version/s: Maven Build - Maint 2007
    Affects Version/s:     (was: Maven Build - Maint 2007)

> Add a feature to dependency plugin to find conflicting versions
> ---------------------------------------------------------------
>
>                 Key: JBBUILD-415
>                 URL: http://jira.jboss.com/jira/browse/JBBUILD-415
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Maven
>            Reporter: Paul Gier
>             Fix For: Maven Build - Maint 2007
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Add a feature to the maven dependency plugin that finds if a dependency tree contains two different versions of the same artifact.
> This could be an additional section in the results of the analyze goal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 14:32:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 31 Aug 2007 14:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-1175)
	Option.forceCall(A)sync
Message-ID: <31286648.1188585138477.JavaMail.jira@cloud.prod.atl2.jboss.com>

Option.forceCall(A)sync
-----------------------

                 Key: JBCACHE-1175
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1175
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
             Fix For: 2.1.0.GA


Add an option to allow an individual call to go async/sync when the cache overall is configured for the opposite.

This would only be relevant to calls not running in a tx; transactional replication would use the standard semantic configured for the cache.

Use case for this is Hibernate timestamp region replication, which needs to go async, while all other Hibernate 2nd level cache traffic goes sync.  A good region-based cache impl would solve the problem as well, but that will surely take quite a while to implement a while while doing it via an Option looks quite 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 lists.jboss.org  Fri Aug 31 14:32:18 2007
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 31 Aug 2007 14:32:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1175)
	Option.forceCall(A)sync
In-Reply-To: <31286648.1188585138477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12812172.1188585138705.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=comments#action_12374821 ] 
            
Brian Stansberry commented on JBCACHE-1175:
-------------------------------------------

Manik, I left this assigned to you in order to get your input, but if you think it's OK to do, feel free to assign back to me.

> Option.forceCall(A)sync
> -----------------------
>
>                 Key: JBCACHE-1175
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1175
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA
>
>
> Add an option to allow an individual call to go async/sync when the cache overall is configured for the opposite.
> This would only be relevant to calls not running in a tx; transactional replication would use the standard semantic configured for the cache.
> Use case for this is Hibernate timestamp region replication, which needs to go async, while all other Hibernate 2nd level cache traffic goes sync.  A good region-based cache impl would solve the problem as well, but that will surely take quite a while to implement a while while doing it via an Option looks quite 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 lists.jboss.org  Fri Aug 31 15:37:18 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 31 Aug 2007 15:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-456) Create annotations
 correpondent to xml tags
Message-ID: <10621792.1188589038704.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create annotations correpondent to xml tags
-------------------------------------------

                 Key: JBAOP-456
                 URL: http://jira.jboss.com/jira/browse/JBAOP-456
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 2.0.0.alpha5
            Reporter: Flavia Rainone
            Priority: Optional


There are configurations that can be done only with xml tags.

This task is about adding annotation configuaration equivalent to all xml tags JBoss AOP supports (except for: tags that already have an annotation equivalent; and for configurations that should be done only in 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 lists.jboss.org  Fri Aug 31 15:37:19 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 31 Aug 2007 15:37:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-456) Create annotations
 correpondent to xml tags
In-Reply-To: <10621792.1188589038704.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8448353.1188589039646.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-456?page=comments#action_12374833 ] 
            
Flavia Rainone commented on JBAOP-456:
--------------------------------------

This task also includes the addition of examples to the tutorial.

> Create annotations correpondent to xml tags
> -------------------------------------------
>
>                 Key: JBAOP-456
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-456
>             Project: JBoss AOP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 2.0.0.alpha5
>            Reporter: Flavia Rainone
>            Priority: Optional
>
> There are configurations that can be done only with xml tags.
> This task is about adding annotation configuaration equivalent to all xml tags JBoss AOP supports (except for: tags that already have an annotation equivalent; and for configurations that should be done only in 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 lists.jboss.org  Fri Aug 31 15:39:26 2007
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Fri, 31 Aug 2007 15:39:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-457) Create annotations
 for Binding advice stacks
Message-ID: <11910965.1188589166019.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create annotations for Binding advice stacks
--------------------------------------------

                 Key: JBAOP-457
                 URL: http://jira.jboss.com/jira/browse/JBAOP-457
             Project: JBoss AOP
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 2.0.0.alpha5
            Reporter: Flavia Rainone
            Priority: Minor


We should allow a way of binding advice stacks by using 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 lists.jboss.org  Fri Aug 31 15:46:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:46:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-641) re-implement the
 callback polling for http transport to reduce latency
In-Reply-To: <4571412.1164899455840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3322395.1188589578458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-641?page=all ]

Ron Sigal closed JBREM-641.
---------------------------

    Resolution: Done

This issue was reopened to add fix version 2.2.2.GA.  It can now be closed again.

> re-implement the callback polling for http transport to reduce latency
> ----------------------------------------------------------------------
>
>                 Key: JBREM-641
>                 URL: http://jira.jboss.com/jira/browse/JBREM-641
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon), 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 15:48:34 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-743) For polling callback
 handler, 
 org.jboss.remoting.Client.addListener() should create only one
 CallbackPoller per InvokerCallbackHandler
In-Reply-To: <28950543.1178341672458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5438893.1188589714008.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-743?page=all ]

Ron Sigal closed JBREM-743.
---------------------------

    Resolution: Done

Unit test is passing on cruisecontrol.

> For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-743
>                 URL: http://jira.jboss.com/jira/browse/JBREM-743
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. 
> The semantics, according to Chapter 5 of the Remoting guide, should be
> If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect.
> So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 15:52:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-747)
 org.jboss.remoting.transport.Connector should unregister server invoker
 from MBeanServer
In-Reply-To: <8850851.1179472312226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26988948.1188589938253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-747?page=all ]

Ron Sigal closed JBREM-747.
---------------------------

    Resolution: Done

The fix has been applied to Remoting 2.2.2.GA (branch remoting_2_2_0_GA).

> org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-747
>                 URL: http://jira.jboss.com/jira/browse/JBREM-747
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one).  
> The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception 
> javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
>         at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
>         at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799)
> The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered.  The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker.   As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory 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 lists.jboss.org  Fri Aug 31 15:56:19 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:56:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18045902.1188590179716.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-749?page=comments#action_12374841 ] 
            
Ron Sigal commented on JBREM-749:
---------------------------------

Mistake in previous comment:  the unit test is org.jboss.test.remoting.transport.bisocket.SecondaryServerSocketTestCase.

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 15:58:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 15:58:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-749)
 BisocketServerInvoker: Make
 configurable the address and port of secondary server socket
In-Reply-To: <10171885.1180688109221.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31112337.1188590298487.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-749?page=all ]

Ron Sigal closed JBREM-749.
---------------------------

    Resolution: Done

The changes have been applied to branch remoting_2_x and the unit test is passing on cruisecontrol.

> BisocketServerInvoker: Make configurable the address and port of secondary server socket
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-749
>                 URL: http://jira.jboss.com/jira/browse/JBREM-749
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Takayoshi Kimura
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol.
> In 2.2.0.GA, it is not configurable:
>          InetAddress host = getServerSocket().getInetAddress();
>          int freePort = PortUtil.findFreePort(host.getHostAddress());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:25:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 16:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-754) Reset timeout on each
 use of HttpURLConnection
In-Reply-To: <3212428.1181272151600.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22825904.1188591918299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-754?page=all ]

Ron Sigal closed JBREM-754.
---------------------------

    Resolution: Done

Now that the changes have appeared in Remoting 2.2.2.GA, this issue can be closed again.

> Reset timeout on each use of HttpURLConnection
> ----------------------------------------------
>
>                 Key: JBREM-754
>                 URL: http://jira.jboss.com/jira/browse/JBREM-754
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Even though each call to org.jboss.remoting.transport.http.HTTPClientInvoker.invoke() creates a new HttpURLConnection, it seems that the HttpURLConnection implementation caches underlying connections.  When an org.jboss.remoting.ConnectionValidator is running, it connects to the same server as ordinary HTTPClientInvokers used by the application, but it sets a timeout of 1000.  If no timeout value is configured for application connections, then HTTPClientInvoker does not set a timeout on the HttpURLConnection, and a connection with a timeout of 1000 might get reused.
> If no timeout is configured, HTTPClientInvoker should explicitly set the HttpURLConnection connect and read timeouts to 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 lists.jboss.org  Fri Aug 31 16:37:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-755) Make
 ConnectorValidator parameters configurable
In-Reply-To: <9961988.1181953572529.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20548126.1188592638570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-755?page=all ]

Ron Sigal closed JBREM-755.
---------------------------

    Resolution: Done

Now that the changes have been applied to Remoting 2.2.2.GA, the issue can be closed again.

> Make ConnectorValidator parameters configurable
> -----------------------------------------------
>
>                 Key: JBREM-755
>                 URL: http://jira.jboss.com/jira/browse/JBREM-755
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Currently org.jboss.remoting.ConnectionValidator hard codes the timeout value (1000 ms) and the number of attempts (1) to get a socket (socket transport family only).  It would be useful to be able to configure these parameters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:37:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access
 to a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12654837.1188592638769.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12374858 ] 
            
Sohil Shah commented on JBPORTAL-1626:
--------------------------------------

This problem is becuase of weird locking issue that crops up with usage of jboss-cache-1.4.1. 

Thats the version packaged with 4.2.1.GA and the way to fix this is to remove the following jar file:

/server-config/lib/jboss-cache-jdk50.jar.

Compatibility with jboss-cache-1.4.1 will have to be looked into further, maybe even probably with some help from JBoss Cache team.

Digging deeper into the issue, in 1.4.1 jboss cache system seems to be timing out trying to grab a read lock on a cache node due to the presence of a write lock on that node.

However, in this usecase, there is clearly no write access being made to the jboss cache node (programmatically), so I am puzzled as to where the write lock on the node is coming from.

Everything works fine when the NodeLockingScheme is set to OPTMISTIC instead of PESSIMISTIC. But, this is not a solution.

For now, in JBoss-4.2.1, the /server-config/lib/jboss-cache-jdk50.jar needs to be deleted, so that the jboss-cache-1.4.0 packaged with the portal release will be used

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:39:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1626) FIrst access to
 a CMS HTML file through /content/ results in a NPE
In-Reply-To: <27106164.1186750621182.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31652829.1188592758664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=all ]

Sohil Shah resolved JBPORTAL-1626.
----------------------------------

    Resolution: Done

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:41:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1669) Make the
 JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
Message-ID: <14562486.1188592878261.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make the JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
-----------------------------------------------------------------------

                 Key: JBPORTAL-1669
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1669
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal CMS
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
            Priority: Minor
             Fix For: 2.6.3 Final


For details look at http://jira.jboss.com/jira/browse/JBPORTAL-1626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:41:18 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1669) Make the
 JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
In-Reply-To: <14562486.1188592878261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <695499.1188592878384.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1669?page=all ]

Sohil Shah updated JBPORTAL-1669:
---------------------------------

    Affects Version/s: 2.6.1 Final
                       2.6.2 Final

> Make the JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1669
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1669
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final, 2.6.2 Final
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.6.3 Final
>
>
> For details look at http://jira.jboss.com/jira/browse/JBPORTAL-1626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 16:43:37 2007
From: jira-events at lists.jboss.org (Sohil Shah (JIRA))
Date: Fri, 31 Aug 2007 16:43:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1669) Make the
 JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
In-Reply-To: <14562486.1188592878261.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31980675.1188593017383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1669?page=comments#action_12374860 ] 
            
Sohil Shah commented on JBPORTAL-1669:
--------------------------------------

JBoss Cache 1.4.1 ships with JBoss-4.2.1, hence this task will help with a better out-of-the-box experience
without requiring the fix mentioned in the refered task

> Make the JBossCachePersistenceManager compatible with JBoss Cache 1.4.1
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1669
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1669
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final, 2.6.2 Final
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.6.3 Final
>
>
> For details look at http://jira.jboss.com/jira/browse/JBPORTAL-1626

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 17:06:13 2007
From: jira-events at lists.jboss.org (Sol Kindle (JIRA))
Date: Fri, 31 Aug 2007 17:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (HIBERNATE-55) No way to
 specify Connection Release Mode in HMBean
In-Reply-To: <3485157.1167733226907.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11850104.1188594373126.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/HIBERNATE-55?page=comments#action_12374868 ] 
            
Sol Kindle commented on HIBERNATE-55:
-------------------------------------

I just upgraded from hibernate 3.0.5 to 3.2.4.sp1 (included with JBoss 4.2.1) and now my application which has been running for two years is getting the "Closing a connection for you.  Please close them yourself" log message and a STACKTRACE.  I am also running hibernate as an MBean. 

1) Is there a workaound for this issue?  
2) Is it OK to just call hsession.close() at the end of the EJB method getting this warning?  Or is this indicative of some other problem.

Thank you.

> No way to specify Connection Release Mode in HMBean
> ---------------------------------------------------
>
>                 Key: HIBERNATE-55
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-55
>             Project: Hibernate
>          Issue Type: Feature Request
>            Reporter: Mohammed Sadiq
>         Assigned To: Steve Ebersole
>
> In my application I have employed an Hibernate MBean for session factory creation and binding it to JNDI and I've added a new overload for the SessionFactory.openSession(Interceptor, ConnectionReleaseMode) method to oveeride the default connection release mode.
>  
> The default connection release mode for any Hibernate session created using the session factory deployed through a Hibernate MBean configuration is taken as "after_statement".
> It will be more helpful, if there exists an MBean attribute "ConnectionReleaseMode" which can thake the enumerated values from the org.hibernate.ConnectionReleaseMode.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 17:15:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 17:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-756) CallbackPoller should
 shut down if too many errors occur.
In-Reply-To: <21704098.1182228191615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27182730.1188594918222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-756?page=all ]

Ron Sigal closed JBREM-756.
---------------------------

    Resolution: Done

Now that the changes have been applied to Remoting 2.2.2.GA, this issue can be closed again.

> CallbackPoller should shut down if too many errors occur.
> ---------------------------------------------------------
>
>                 Key: JBREM-756
>                 URL: http://jira.jboss.com/jira/browse/JBREM-756
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.callback.CallbackPoller will keep running even if the connection is broken or server crashes.  It should be possible to specify a maximum number of errors, after which CallbackPoller will quit polling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 17:35:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1670) Add styling to
 Portal object names outside of tables
Message-ID: <4041277.1188596118220.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add styling to Portal object names outside of tables
----------------------------------------------------

                 Key: JBPORTAL-1670
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1670
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Fri Aug 31 17:35:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1670) Add styling to
 Portal object names outside of tables
In-Reply-To: <4041277.1188596118220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3494907.1188596118307.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1670?page=all ]

Chris Laprun resolved JBPORTAL-1670.
------------------------------------

    Fix Version/s: 2.6.2 Final
                   2.8 Final
       Resolution: Done

> Add styling to Portal object names outside of tables
> ----------------------------------------------------
>
>                 Key: JBPORTAL-1670
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1670
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.2 Final, 2.8 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 lists.jboss.org  Fri Aug 31 17:35:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1671) Rework portlet
 definitions page
Message-ID: <17374104.1188596118417.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rework portlet definitions page
-------------------------------

                 Key: JBPORTAL-1671
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1671
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         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 lists.jboss.org  Fri Aug 31 17:37:18 2007
From: jira-events at lists.jboss.org (Chris Laprun (JIRA))
Date: Fri, 31 Aug 2007 17:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1671) Rework portlet
 definitions page
In-Reply-To: <17374104.1188596118417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19852006.1188596238194.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1671?page=all ]

Chris Laprun updated JBPORTAL-1671:
-----------------------------------

          Component/s: Portal Core Admin
        Fix Version/s: 2.6.2 Final
                       2.8 Final
    Affects Version/s: 2.6.1 Final
             Priority: Minor  (was: Major)

> Rework portlet definitions page
> -------------------------------
>
>                 Key: JBPORTAL-1671
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1671
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core Admin
>    Affects Versions: 2.6.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.8 Final, 2.6.2 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 lists.jboss.org  Fri Aug 31 17:48:18 2007
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Fri, 31 Aug 2007 17:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-278) endpoint reference in
 <from> is not validated against the available partner link roles
Message-ID: <12462989.1188596898196.JavaMail.jira@cloud.prod.atl2.jboss.com>

endpoint reference in <from> is not validated against the available partner link roles
--------------------------------------------------------------------------------------

                 Key: BPEL-278
                 URL: http://jira.jboss.com/jira/browse/BPEL-278
             Project: JBoss jBPM BPEL
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Engine
    Affects Versions: jBPM BPEL 1.1 beta 3
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1 GA


Consider the following partner link declaration.

<partnerLink name="ConfiscationTaskMngLink" partnerLinkType="wsdl:ConfiscationTaskMngLink" partnerRole="ConfiscationTaskMngProvider" />

The following from-spec is invalid because the above partner link does not specify myRole:

<from endpointReference="myRole" partnerLink="ConfiscationTaskMngLink" />

This error is not caught during static analysis.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:05:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:05:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4974280.1188605118214.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-757?page=comments#action_12374880 ] 
            
Ron Sigal commented on JBREM-757:
---------------------------------

The test method additions did not properly test polled callbacks.

Now, testQuickRemoveListener has been split into testQuickRemovePushListener() and testQuickRemovePullListner, and testQuickRemoveListenerZeroTimeout has been split into testQuickRemovePushListenerZeroTimeout and testQuickRemovePullListenerZeroTimeout.  For transports that are not bidirectional, quick versions of Client.disconnect() and quick Client.removeListener()  will be tested for polled callbacks.

Also, unit tests have been added for the bisocket transport.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:12:33 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:12:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7662425.1188605553692.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-757?page=comments#action_12374881 ] 
            
Ron Sigal commented on JBREM-757:
---------------------------------

Set log level to DEBUG for SocketQuickDisconnectTestCase in response to cruisecontrol failure: http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html.

Don't forget to reset it to INFO before closing issue.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:12:33 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:12:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8828130.1188605553850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-757?page=all ]

Ron Sigal updated JBREM-757:
----------------------------

    Fix Version/s:     (was: 2.2.2.GA)

Removing fix version 2.2.2.GA, which has been release.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:16:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:16:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-761) NPE in
 BisocketServerInvoker$ControlConnectionThread
In-Reply-To: <9608977.1183001997620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19649052.1188605778307.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-761?page=all ]

Ron Sigal closed JBREM-761.
---------------------------

    Fix Version/s:     (was: 2.4.0.Beta1 (Pinto))
       Resolution: Done

The fix has been applied to branch remoting_2_x.  Branch remoting_2_2_0_SP4_CP will be eliminated, since Remoting 2.2.2.GA will be used in place of a CP update of 2.2.0.SP4.

> NPE in BisocketServerInvoker$ControlConnectionThread
> ----------------------------------------------------
>
>                 Key: JBREM-761
>                 URL: http://jira.jboss.com/jira/browse/JBREM-761
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.2.2.GA
>
>
> From Tim Fox:
> Here's one I saw today:
> @main 18:11:54,129 INFO  [FailoverTest] tearing down
> Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException
>        at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669)
> It seems pretty harmless, but nevertheless I thought I'd inform 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 lists.jboss.org  Fri Aug 31 20:31:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:31:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-766) Guard against
 "spurious wakeup" from Thread.sleep()
In-Reply-To: <30241142.1184001511621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15338341.1188606678260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-766?page=all ]

Ron Sigal closed JBREM-766.
---------------------------

    Resolution: Done

Changes have been applied to branch remoting_2_x.

> Guard against "spurious wakeup" from Thread.sleep()
> ---------------------------------------------------
>
>                 Key: JBREM-766
>                 URL: http://jira.jboss.com/jira/browse/JBREM-766
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
> A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
>      synchronized (obj) {
>          while (<condition does not hold>)
>              obj.wait(timeout);
>          ... // Perform action appropriate to condition
>      }
>  
> (For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
> We should make sure all calls to Thread.wait() are handled appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:33:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:33:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-771)
 MicroSocketClientInvoker can experience socket leaks
In-Reply-To: <12805046.1184112691618.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21426049.1188606798230.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-771?page=all ]

Ron Sigal closed JBREM-771.
---------------------------

    Resolution: Done

The changes have been applied to branch remoting_2_x, and the unit test passes on cruisecontrol.

> MicroSocketClientInvoker can experience socket leaks
> ----------------------------------------------------
>
>                 Key: JBREM-771
>                 URL: http://jira.jboss.com/jira/browse/JBREM-771
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools.  When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map.  Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool.  However, it still has a connection pool, accessible through an instance variable.  So each MicroSocketClientInvoker should be sure to clear its own connection pool.
> .
> Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator.  Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete.  This conjecture should be verified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:35:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:35:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-774)
 BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should
 close control socket
In-Reply-To: <6131196.1184213431580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28602650.1188606918274.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-774?page=all ]

Ron Sigal closed JBREM-774.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x, and the unit test passes on cruisecontrol.

> BisocketClientInvoker.replaceControlSocket() and handleDisconnect() should close control socket
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBREM-774
>                 URL: http://jira.jboss.com/jira/browse/JBREM-774
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> If cpu overload or network congestion causes a control connection PING to get delayed, the client side org.jboss.remoting.transport.bisocket.Bisocket.BisocketServerInvoker.ControlMonitorTimerTask will tell the server side BisocketServerInvoker.SecondaryServerSocketThread to replace the control socket.  
> If org.jboss.remoting.transport.bisocket.Bisocket.BisocketClientInvoker.replaceControlSocket() does not close the old control socket, and if the client is still alive, the client side BisocketServerInvoker.ControlConnectionThread will be blocked trying to read from an old control connection, which is no longer in use on the server side.
> Also, BisocketClientInvoker.handleDisconnect() should close the control socket.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:37:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-775)
 MicroSocketClientInvoker.initPool() should omit pool from log message
In-Reply-To: <22847641.1184220151562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27941810.1188607038317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-775?page=all ]

Ron Sigal closed JBREM-775.
---------------------------

    Resolution: Done

Fix has been applied to branch remoting_2_x.

> MicroSocketClientInvoker.initPool() should omit pool from log message
> ---------------------------------------------------------------------
>
>                 Key: JBREM-775
>                 URL: http://jira.jboss.com/jira/browse/JBREM-775
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Clebert Suconic reports a ConcurrentModificationException:
> Producer:3 01:00:42,861 INFO  [SeveralClientsStressTest$Producer] Sending Exception
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>         at java.util.AbstractCollection.toString(AbstractCollection.java:453)
>         at java.lang.String.valueOf(String.java:2577)
>         at java.lang.StringBuffer.append(StringBuffer.java:220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
>         at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
>         at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
>         at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
>         at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
>         at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
>         at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
>         at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>         at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>         at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
>         at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324) 
> thrown in the line
>      log.debug(this + " using pool (" + pool + ") already defined for " + address);
> in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool().  pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements.  These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:39:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-778)
 BisocketServerInvoker.start() creates a new static Timer each time
In-Reply-To: <3736496.1184968967071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12955523.1188607158245.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-778?page=all ]

Ron Sigal closed JBREM-778.
---------------------------

    Resolution: Done

Fix has been applied to branch remoting_2_x, and unit test passes on cruisecontrol.

> BisocketServerInvoker.start() creates a new static Timer each time
> ------------------------------------------------------------------
>
>                 Key: JBREM-778
>                 URL: http://jira.jboss.com/jira/browse/JBREM-778
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start() creates a new static Timer each time.  It should only create a new Timer if (1) there is no existing Timer, or (2) the existing Timer has shut down.  See the similar issue JBREM-748.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:51:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-782) Remove network i/o
 from synch
 block in ServerInvokerCallbackHandler.getCallbackHandler()
In-Reply-To: <17977986.1185663407167.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13316879.1188607878230.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-782?page=all ]

Ron Sigal closed JBREM-782.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x.

> Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-782
>                 URL: http://jira.jboss.com/jira/browse/JBREM-782
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block.,  ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:54:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:54:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-784) Use separate maps for
 control sockets and ordinary sockets in BisocketClientInvoker
In-Reply-To: <23905946.1185682907071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13265663.1188608058202.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-784?page=all ]

Ron Sigal closed JBREM-784.
---------------------------

    Resolution: Done

Fix has been applied to branch remoting_2_x, and unit test passes on cruisecontrol.

> Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker
> -----------------------------------------------------------------------------------
>
>                 Key: JBREM-784
>                 URL: http://jira.jboss.com/jira/browse/JBREM-784
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> A race condition can cause control sockets and ordinary sockets to be confused with each other.  In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side.  The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:56:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-785)
 BisocketClientInvoker.transport()
 inadvertently uses listenerId member variable
In-Reply-To: <29284826.1186038776785.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23500502.1188608191403.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-785?page=all ]

Ron Sigal closed JBREM-785.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x, and the unit test passes on cruisecontrol.

> BisocketClientInvoker.transport() inadvertently uses listenerId member variable
> -------------------------------------------------------------------------------
>
>                 Key: JBREM-785
>                 URL: http://jira.jboss.com/jira/browse/JBREM-785
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack.  As a result, there is a race condition if multiple org.jboss.remoting.Client's call addListener() on the same server.  Each entering thread would attempt to add a (listenerId, BisocketClientInvoker) pair to listenerIdToClientInvokerMap, and under the right circumstances, one or more of the threads could experience the overwriting of the listenerId variable, which would lead to a missing pair in listenerIdToClientInvokerMap.
> The fix is just to use a stack variable instead of the member variable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:56:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-787) Move network i/o in
 BisocketClientInvoker constructor to handleConnect()
In-Reply-To: <9475225.1186260970610.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26481091.1188608191523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-787?page=all ]

Ron Sigal closed JBREM-787.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x.

> Move network i/o in BisocketClientInvoker constructor to handleConnect()
> ------------------------------------------------------------------------
>
>                 Key: JBREM-787
>                 URL: http://jira.jboss.com/jira/browse/JBREM-787
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block.  InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 20:56:31 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 20:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-788) Access to
 BisocketClientInvoker
 static maps should be synchronized in handleDisconnect()
In-Reply-To: <33283151.1186281769342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <793843.1188608191634.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-788?page=all ]

Ron Sigal closed JBREM-788.
---------------------------

    Resolution: Done

The fix has been applied to branch remoting_2_x.

> Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-788
>                 URL: http://jira.jboss.com/jira/browse/JBREM-788
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:02:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-790) NPE in
 BisocketClientInvoker$PingTimerTask
In-Reply-To: <4122839.1186630729288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29808709.1188608538265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-790?page=all ]

Ron Sigal closed JBREM-790.
---------------------------

    Resolution: Done

A "running" variable has been added to PingTimerTask in conjunction with JBREM-797, which leads to a slightly different solution on the remoting_2_x branch.

> NPE in BisocketClientInvoker$PingTimerTask
> ------------------------------------------
>
>                 Key: JBREM-790
>                 URL: http://jira.jboss.com/jira/browse/JBREM-790
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null.  If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of 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 lists.jboss.org  Fri Aug 31 21:02:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-794)
 LeasePinger.addClient() should not
 create a new LeaseTimerTask if none currently exists
In-Reply-To: <18755133.1187587681051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2059694.1188608538408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-794?page=all ]

Ron Sigal closed JBREM-794.
---------------------------

    Resolution: Done

Unit test passes on cruisecontrol.

> LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists
> ---------------------------------------------------------------------------------------
>
>                 Key: JBREM-794
>                 URL: http://jira.jboss.com/jira/browse/JBREM-794
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> When org.jboss.remoting.LeasePinger.addClient() adds a new org.jboss.remoting.Client with a shorter ping period, it restarts the LeaseTimerTask.  However, org.jboss.remoting.MicroRemoteClientInvoker.establishLease() calls LeasePinger.addClient() before it calls LeasePinger.startPing().  LeasePinger incorrectly creates a LeaseTimerTask in addClient() and then creates a second one in startPing().
> LeasePinger.addClient() should be changed so that it starts a new LeaseTimerTask only if one already 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 lists.jboss.org  Fri Aug 31 21:14:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:14:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-798) Implement quick
 Client.removeListener() for polled callbacks, part 2
Message-ID: <26306549.1188609258232.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement quick Client.removeListener() for polled callbacks, part 2
--------------------------------------------------------------------

                 Key: JBREM-798
                 URL: http://jira.jboss.com/jira/browse/JBREM-798
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


This issue is a continuation of JBREM-757.   There are two additions:

1. The unit tests org.jboss.test.remoting.transport.http.timeout.HttpQuickDisconnectTestCase and org.jboss.test.remoting.transport.socket.timeout.SocketQuickDisconnectTestCase did not properly test the the quick version of org.jboss.remoting.Client.removeListener() in the case of polled callbacks.

2. The facility should be tested for the RMI transport when per invocation timeouts are implemented for that transport. (See JBREM-701.)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:18:29 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30135738.1188609509447.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-757?page=all ]

Ron Sigal updated JBREM-757:
----------------------------

    Fix Version/s: 2.2.2.GA
                       (was: 2.4.0.Beta1 (Pinto))

Adding fix version 2.2.2.GA back.  No more changes will be made for 2.2.2.GA.  The remaining concerns associated with this issue will be addressed in Remoting 2.4.0 in conjunction with JBREM-798.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:20:22 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:20:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-757) Implement quick
 Client.removeListener() for polled callbacks.
In-Reply-To: <15722418.1182233051608.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33009081.1188609622950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-757?page=all ]

Ron Sigal closed JBREM-757.
---------------------------

    Resolution: Done

All further concerns related to this issue will be addressed in Remoting 2.4.0 in conjunction with JBREM-798.

> Implement quick Client.removeListener() for polled callbacks.
> -------------------------------------------------------------
>
>                 Key: JBREM-757
>                 URL: http://jira.jboss.com/jira/browse/JBREM-757
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods.  The per invocation timeout is set by calling Client.setDisconnectTimeout().  When the disconnect timeout is set to 0, network i/o is avoided entirely.
> However, the quick version of Client.removeListener() was implemented only for push callbacks.  It should also be implemented for pull callbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:25:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:25:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-789) Release 2.2.2.GA
In-Reply-To: <22334586.1186595449377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21068690.1188609918208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-789?page=all ]

Ron Sigal updated JBREM-789:
----------------------------

        Fix Version/s:     (was: 2.4.0.Beta1 (Pinto))
    Affects Version/s: 2.2.2.GA
                           (was: 2.4.0.Beta1 (Pinto))
                           (was: 2.2.0.SP4)
                           (was: 2.2.1.GA)

> Release 2.2.2.GA
> ----------------
>
>                 Key: JBREM-789
>                 URL: http://jira.jboss.com/jira/browse/JBREM-789
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>         Attachments: jboss-remoting.jar, jboss-remoting.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 lists.jboss.org  Fri Aug 31 21:39:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-731) Address of secondary
 server
 socket should be acquired each time a control connection is created.
In-Reply-To: <2294620.1175908141216.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <418254.1188610758231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-731?page=all ]

Ron Sigal updated JBREM-731:
----------------------------

    Fix Version/s: 2.2.2.GA

Adding fix version 2.2.2.GA, since this issue was, in fact, resolved in 2.2.2.GA.

> Address of secondary server socket should be acquired each time a control connection is created.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-731
>                 URL: http://jira.jboss.com/jira/browse/JBREM-731
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.GA (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.GA
>
>
> Scenario:  Client is connected to a server, server dies, and server is restarted (with same InvokerLocator).  The new server creates a secondary server socket on a different port than the previous server, but the client invoker retains the old secondary server socket InvokerLocator.  When a new Client is created, the old client invoker gets reused, and it isn't possible to create a control connection.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:41:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:41:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-731) Address of secondary
 server socket
 should be acquired each time a control connection is created.
In-Reply-To: <2294620.1175908141216.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33239140.1188610878224.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-731?page=all ]

Ron Sigal closed JBREM-731.
---------------------------

    Resolution: Done

Unit tests pass on cruisecontrol.

> Address of secondary server socket should be acquired each time a control connection is created.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-731
>                 URL: http://jira.jboss.com/jira/browse/JBREM-731
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.GA (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Scenario:  Client is connected to a server, server dies, and server is restarted (with same InvokerLocator).  The new server creates a secondary server socket on a different port than the previous server, but the client invoker retains the old secondary server socket InvokerLocator.  When a new Client is created, the old client invoker gets reused, and it isn't possible to create a control connection.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:48:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:48:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-799) Add a separate
 timeout parameter for callback clients, part 2
Message-ID: <4676162.1188611298194.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a separate timeout parameter for callback clients, part 2
-------------------------------------------------------------

                 Key: JBREM-799
                 URL: http://jira.jboss.com/jira/browse/JBREM-799
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


This issue is a continuation of JBREM-765 "Add a separate timeout parameter for callback clients".  

The changes have been applied to branches remoting_2_2_0_GA and remoting_2_x, but unit tests exist only for transports socket and bisocket.  A unit test should be written for the RMI transport as well.  However, no additional changes will be made to Remoting 2.2.2.GA, so this issue is introduced for 2.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 lists.jboss.org  Fri Aug 31 21:52:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:52:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-765) Add a separate
 timeout parameter for callback clients
In-Reply-To: <10089504.1183706280253.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1645319.1188611538457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-765?page=all ]

Ron Sigal closed JBREM-765.
---------------------------

    Resolution: Done

The provision of a unit test for the RMI transport will be done under JBREM-799 "Add a separate timeout parameter for callback clients, part 2".

> Add a separate timeout parameter for callback clients
> -----------------------------------------------------
>
>                 Key: JBREM-765
>                 URL: http://jira.jboss.com/jira/browse/JBREM-765
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> Currently, the timeout set for the server filters down to callback client invokers.  However, it would be useful to be able to specify a different timeout value for callback clients.
> Example.  In JBossMessaging the server timeout is set to 0.  This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait().  If timeout == 0 and the client dies, then the thread in wait() could wait forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 21:59:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 21:59:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-767) Avoid deadlock in
 callback BisocketClientInvoker when timeout == 0
In-Reply-To: <18200327.1184001991571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27042680.1188611958279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-767?page=all ]

Ron Sigal closed JBREM-767.
---------------------------

    Resolution: Done

Fixes for JBREM-765, JBREM-787, and having BisocketClientInvoker.handleDisconnect() wake up any threads waiting in BisocketClientInvoker.createSocket() have been applied to branch remoting_2_x.

The proposed fix "Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client fails." has not been implemented, since it adds a function for which PingTimerTask was not designed.

The unit test is passing on cruisecontrol.

> Avoid deadlock in callback BisocketClientInvoker when timeout == 0
> ------------------------------------------------------------------
>
>                 Key: JBREM-767
>                 URL: http://jira.jboss.com/jira/browse/JBREM-767
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP4, 2.2.1.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto)
>
>
> If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable.  
> One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate.  One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765).
> Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client 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 lists.jboss.org  Fri Aug 31 22:01:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 22:01:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-796) Verify Remoting 2.2.2
 is compatible with earlier versions
In-Reply-To: <17644775.1187843058201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4442627.1188612078204.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-796?page=all ]

Ron Sigal closed JBREM-796.
---------------------------

    Resolution: Done

Running tests.versioning.all shows that Remoting from branch 2_2_0_GA tagged remoting_2_2_2_GA (i.e., Remoting 2.2.2.GA) is compatible with versions:

   2_2_0_SP4
   2_0_0_GA
   1_4_6_GA
   1_4_4_GA
   1_4_3_GA

> Verify Remoting 2.2.2 is compatible with earlier versions
> ---------------------------------------------------------
>
>                 Key: JBREM-796
>                 URL: http://jira.jboss.com/jira/browse/JBREM-796
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.GA
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.GA
>
>
> Need to add version 2.2.0.SP4 jboss-remoting.jar to src/etc/lib and run tests.versioning.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 lists.jboss.org  Fri Aug 31 23:38:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 23:38:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-800) Adjust timout values
 to avoid cruisecontrol failures
Message-ID: <29811097.1188617898218.JavaMail.jira@cloud.prod.atl2.jboss.com>

Adjust timout values to avoid cruisecontrol failures
----------------------------------------------------

                 Key: JBREM-800
                 URL: http://jira.jboss.com/jira/browse/JBREM-800
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


It seems that some tests fail on cruisecontrol because a busy machine causes timout deadlines to be missed.  For example, 

    http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html

This issue will be an umbrella issue to cover adjusting timeout values.  If a test continues to fail despite updated timeout values, it will need a JIRA issue of its own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 23:45:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 23:45:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-800) Adjust timout
 values to avoid cruisecontrol failures
In-Reply-To: <29811097.1188617898218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1807917.1188618318249.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-800?page=comments#action_12374911 ] 
            
Ron Sigal commented on JBREM-800:
---------------------------------

The cruisecontrol failure referenced above was org.jboss.test.remoting.transport.socket.timeout.CallbackTimeoutTestCase(java_serialization).

> Adjust timout values to avoid cruisecontrol failures
> ----------------------------------------------------
>
>                 Key: JBREM-800
>                 URL: http://jira.jboss.com/jira/browse/JBREM-800
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> It seems that some tests fail on cruisecontrol because a busy machine causes timout deadlines to be missed.  For example, 
>     http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html
> This issue will be an umbrella issue to cover adjusting timeout values.  If a test continues to fail despite updated timeout values, it will need a JIRA issue of its own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Aug 31 23:50:18 2007
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 31 Aug 2007 23:50:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-800) Adjust timout
 values to avoid cruisecontrol failures
In-Reply-To: <29811097.1188617898218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25089115.1188618618227.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-800?page=comments#action_12374912 ] 
            
Ron Sigal commented on JBREM-800:
---------------------------------

Extended timeout to 2000 in org.jboss.test.remoting.transport.socket.timeout.CallbackTimeoutTestCase.testOnewayCallbackTimeout().

> Adjust timout values to avoid cruisecontrol failures
> ----------------------------------------------------
>
>                 Key: JBREM-800
>                 URL: http://jira.jboss.com/jira/browse/JBREM-800
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.Beta1 (Pinto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.Beta1 (Pinto)
>
>
> It seems that some tests fail on cruisecontrol because a busy machine causes timout deadlines to be missed.  For example, 
>     http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/20070831112548/results/index.html
> This issue will be an umbrella issue to cover adjusting timeout values.  If a test continues to fail despite updated timeout values, it will need a JIRA issue of its own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


